Re: [tsvwg] UDP options and header-data split (zero copy)

[Joseph Touch <[e-mail]>]

> On Jul 17, 2021, at 6:05 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Sat, Jul 17, 2021 at 4:06 PM Joe Touch <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Jul 17, 2021, at 2:58 PM, Tom Herbert <[e-mail]> wrote:
>>> 
>>> If I'm reading the draft correctly, it is possible that UDP options
>>> could appear both in the headers and trailers of a packet. If that is
>>> correct, then that means an implementation needs to be able to handle
>>> both headers and trailers within the *same* packet.
>> 
>> That is always the case for non-fragmented packets - the only mode that supports transparent use of options that don’t change the payload data with legacy receivers.
> 
> Perhaps I'm not reading it correctly, but it seems like in legacy mode
> all options are in trailers in the surplus area. In the last fragment
> case, the packet may look like
> UDP-header/UDP-options-per-packet/Frag-data-UDP-options-for-reassembled-packets.
> So in that case, there are UDP options in both headers and trailers in
> the same packet.

Again, that happens for legacy packets too - the existing UDP header is in the front and options are in the trailer.

> If that's true, then a device that can't handle
> protocol headers can't handle the case where there are trailing
> options in the last fragment.

I can’t parse this in a way that makes sense. A device that can’t handle protocol headers can’t do UDP’s existing header. A device that can’t ALSO handle trailers can’t process UDP options for non-fragment packets.

> If those options were in the headers
> instead, then it could handle that case. Or maybe the idea is that a
> receiver can ignore options after the last fragment data since they
> are in trailers like legacy mode?

The idea is that, after reassembly, UDP processing *continues exactly as it would for a non-reassembled packet.

Those trailing options apply to the WHOLE reassembled packet, not just the final fragment.

Joe