Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt

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

On Tue, Feb 28, 2017 at 3:15 PM, Joe Touch <[e-mail]> wrote:
> Consider this:
>
> if we use LITE before FRAG as you propose, then the reassembled result
> has no checksum yet.
>
> so the FRAG header could incorporate LITE if it used two different
> length fields: one for the whole length, one for the checksummed length.
>
> I.e., rather than require full "option" processing after FRAG, we could
> build LITE support into FRAG itself.
>
> Would that make sense?

I definitely like the idea of building LITE support into FRAG,
particularly if one of the side effects is that we always hide
fragments from legacy implementations. But let me walk through
it to make sure that I understand how it would work.

With LITE at the beginning of the payload before FRAG, as I initially
suggested, the UDP length is 8 and the UDP checksum protects only
the UDP header. LITE specifies how much of the surplus area is user
data; the rest is transport options, including FRAG itself. FRAG
specifies the fragment offset, the M bit, the identification, and
(if the rest of my suggestion is accepted), a post-reassembly length
and checksum,

If FRAG were to incorporate LITE, it would still appear immediately
after the UDP header (which would be unchanged). If you want to
incorporate per-fragment UDP options, FRAG would now need to have
the offset to the remaining UDP options. So, its fields would now
be: kind, length (16 bytes),  fragment offset, M bit, identification,
post-reassembly length that was checksummed, checksum value,
post-reassembly length that was not checksummed, and offset to
remaining options. Is that what you had in mind? If so, it would
certainly work for me.

I believe that a technically viable alternative would be to have instead
per-fragment length that was checksummed, checksum value, and per-fragment
length that was not checksummed. In that case the offset to the remaining
options could be inferred. Another alternative would be to use post-reassembly
values and only one set of UDP options for the entire message; the options
would then be whatever surplus remained after the last fragment was
reassembled, and a separate length field again would not be needed.

Let me mention in passing that I tend to agree with the sentiment that
the standard Internet checksum is probably the right way to go. If that
is provided for the entire reassembled message, you will have feature
parity with what is provided by UDP + IP fragmentation.

Mike Heard