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

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

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