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

[Joe Touch <[e-mail]>]

> On Aug 2, 2021, at 11:56 AM, Sebastian Moeller <[e-mail]> wrote:
> 
> Mmmh, I have  a quick question, actually two.
> 
> 
> a) who is the intended audience of the fragmentation feature? And why is IP or application level "fragmentation? not enough?

Any protocol using UDP where IP fragmentation won’t work - the most notable example is NAT traversal.  IP doesn’t copy the UDP ports into each fragment but UDP option fragmentation does. 

> b) instead of a trailer just add a bit to each option to denote per fragment or per aggregate, sure each option gets one bit longer, but on the flip side no trailer...

At a minimum, because there are options that could be used in either place, eg. OCS, AUTH, and ENCR at least. 

As noted, this won’t avoid the trailer for legacy mode. 

Joe

> 
> Regards
>    Sebastian
> 
> 
> 
> 
>> On Aug 2, 2021, at 20:12, C. M. Heard <[e-mail]> wrote:
>> 
>>> On Mon, Aug 2, 2021 at 7:38 AM Tom Herbert wrote:
>>> No, it's not simpler for an implementation. In the current design
>>> options are in trailers for legacy mode and headers in non-legacy mode
>>> so by definition we need divergent code paths code paths for those two
>>> case. In the non-legacy mode case we need to support both options in
>>> headers and options in trailers within the same packet which
>>> contradicts the principle of having fewer ways to do the same thing.
>>> In any case, having divergent code paths isn't a problem for
>>> implementations, the real complication to implementations would be the
>>> requirement to process protocol trailers.
>> 
>> Actually, in non-legacy mode options may appear BOTH in headers (for
>> per-fragment options) AND in trailers (for the per-datagram options),
>> and in the current draft the latter can fill a complete fragment. An
>> upcoming revision is pending that will change this to allow the options
>> trailer to span multiple fragments.
>> 
>> As I understand it, the procedure (in concept) is to create a datagram
>> in legacy format with its per-datagram options, and then split that up
>> into fragments, each of which can have its own per-fragment options.
>> The per-fragment options precede the corresponding fragment data; in
>> the current draft, the  per-datagram options follow the data in the
>> final fragment.
>> 
>> The upcoming revision will change this a bit ... FRAG END in the
>> terminal FRAG option will be replaced with USER DATA LENGTH. In this
>> case the per-datagram options will be carried within the fragment
>> data. It won't be possible, in general, to tell where the user data
>> ends and the options begin until the reassembly process is complete.
>> 
>> Joe: please offer corrections if I have misrepresented your intent in
>> the thumbnail sketch above.
>> 
>> WG: I understand Joe's point about conceptual simplicity in a common
>> format for all cases, but I have to agree with Tom's point that having
>> divergent code paths isn't the main problem for implementations,
>> overall complexity is, and I remain concerned about what I perceive as
>> the ever-growing complexity of the fragmentation and reassembly
>> specification for UDP options.
>> 
>> Mike Heard
>