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

[Sebastian Moeller <[e-mail]>]

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?

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...

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