Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07

["C. M. Heard" <[e-mail]>]

On Sat, 9 Mar 2019 11:28:57 -0800 Joe Touch wrote:
>
> This one’s a bit long - we need to converge quickly if the draft is going
> to be updated in time for the cutoff.
>
> Please comment asap…
>
> Joe
>
> PS =  yes, we talk about TLV but need to explain that some options are
> exceptions (OCS, NOP, EOL). I also need to update the OCS to be 3 bytes
> long (in the table and figure). Those are in addition to the issues below.
>
> -------
>
> Raffaelo and Mike both pointed out:
>
> > On Mar 9, 2019, at 5:23 AM, C. M. Heard <[e-mail]> wrote:
> > ...
> > the errant middleboxes that CCO is designed to work around do not use
the
> > correct length value in their (re)computation of the UDP checksum. ...
>
> Well, there are several implications here:
>
> 1. we can add in the option length, BUT that also means:
>         (a) we need to declare that the option area consumes the whole of
>         the surplus area (no chance for other uses)
>         OR
>         (b) that the surplus area is always zero
>         OR
>         (c) that OCS covers even the surplus area (it doesn’t need to be
>         zero; it does need to be included)
>
>         we need a choice here. AFAICT, the safest (a)

I agree with that.

> 2. we don’t need OCS alignment; what we do need is to “coordinate” the
 alignment of a 16-bit of the length to the OCS checksum field
>         i.e.:
>         - calculate the length needed (IPlen - UDP len)
>         - if OCS checksum field is not 16-bit aligned to the start of the
>           option area, then swap bytes
>         - add the result to the OCS checksum (‘pseudo header’ seems a bit
>           heavy here, but same point)

I believe that is correct. Padding could still be convenient, though,
and I see no reason to disallow it (the current draft does permit
padding for alignment).

> As Derek noted:
> > As I recall the LITE+FRAG use case has no data in the UDP payload
> > (i.e UDP header length is zero)?
> >
> > For this case, there is another way to work around a broken path (be it
> > boxes, NICs, or whatever), that is simply to send with UDP header
checksum
> > of zero, and contain any necessary checksums in the UDP slack space.
>
>
> 3. we have to deal with LITE/LITE+FRAG
>         we *can* use UDP CS=0, but that also may involve overriding the
>         user’s desires here (i.e., the user API says “use UDP CS” and
we’re
>         not doing that) which means we have a choice:
>         (d) override so that things work, i.e., force UDP CS=0 and then
>                 (d.1) do OCS as a check on our stuff only
>                 OR
>                 (d.2) disallow the use of OCS (if CS=0, what’s the point?)
>                 OR
>                 (d.3) use OCS=0 (this seems like a waste)
>         OR
>         (e) ignore the user setting of CS, then:
>                 (e.1) always do OCS as a check
>                 OR
>                 (e.2) if UDP CS=0, omit OCS (save space), basically like
d.2
>                 OR
>                 (e.3) if UDP CS=0, use OCS=0 (basically like e.2
>
> If we do any of the (e) variants, we could either:
>         (f.1) require users to disable UDP CS to use OCS
>         OR
>         (f.2) ignore the user UDP CS setting
>
> So which is it?
>
> I don’t like assuming user correct configuration (f.1).
>
> So to me it’s (f.2) and (d.1).
>
> Thoughts?

I'm skeptical about this proposal, because it requires making a for
how OCS is calculated for the specific case of LITE+FRAG, and there
are all manner of corner cases that will make that difficult to draft.
In addition, the UDP header itself would not be covered by a checksum,
irrespective of the user UDP CS setting.

I'd like to float a different idea, namely, putting the UDP user data
inside the FRAG option itself. Terminal and non-terminal FRAG options
would need to be distinguished in some manner other than the Length
field; one way is to allocate different Kind code points, as shown below.

                   +--------+--------+--------+--------+
                   | Kind=X |Len=8+k |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+

                   ...                               ...
                   |             User Data             |

                   ...                               ...
                   +--------+--------+--------+--------+


UDP non-terminal FRAG option format



                   +--------+--------+--------+--------+
                   | Kind=Y |Len=10+k|  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+

                   ...                               ...
                   |             User Data             |

                   ...                               ...
                   +--------+--------+--------+--------+

| Checksum | +--------+--------+ UDP terminal FRAG option format


The following requirements would apply:

   >> A host that wishes to signal that it is able to accept and process
   the FRAG option MAY do so by transmitting an unfragmented datagram
   with an empty terminal FRAG option with Offset zero and length 12.


   >> Non-empty FRAG options MUST NOT be present in packets with
   ordinary UDP user data. Any such options MUST be silently
   dropped.


   >> UDP options other than OCS and padding MUST NOT accompany the FRAG
   option in non-terminal fragments. Any such options MUST be silently
   dropped. All other options that apply to a reassembled packet must
   accompany the FRAG header in the terminal fragment.


My thinking is that if user UDP CS setting specifies that the UDP
checksum should be zero, then OCS would not accompany the FRAG
option. Otherwise it would, irrespective of the user OCS setting.

It is true there is the potential for excess work when the user UDP
CS setting is non-zero, because there are checksums that cover both
the individual fragments and the reassembled UDP datagram. However,
most of that work can be avoided by a well-designed implementation
that caches partial checksums during the reassembly process and
sums those to calculate the overall checksum. Alternatively, one
could omit the overall checksum in terminal FRAG options.

Since there is a looming submission deadline, it may be better to
develop this proposal further on the mailing list before putting it
into a draft.

> also Derek noted:
>
> > The OCS/CCO case can cover that, except for the LITE (w/o FRAG) case.
> >
> > For the latter I guess we could also use UDP checksum of zero, and have
> > an option to restore a proper checksum for the UDP data at the receiver,
> > however that will still leave legacy receivers experiencing such packets
> > as unchecksumed.
>
>
> 5. the LITE only case
...
>
> IMO, we leave this one alone. [... T]here are three points to LITE:
>
> 1. less work for the transmitter (which your proposal defeats)
> 2. less work for the receiver (which your proposal maintains)
> 3. deliver potentially corrupted data (one of the original points of
> UDP-lite - it wasn’t just about performance)
>
> These errant middle boxes are also thus defeating #3.
>
> So, IMO, in the presence of those sorts of things, basically LITE with our
> proposal doesn’t do most of what it was intended.

I agree with this. My take is that if LITE is to remain in the spec, then it
should not be covered by OCS. The workaround would defeat its purpose.

Mike Heard