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

[Joseph Touch <[e-mail]>]

> On Aug 1, 2021, at 3:48 PM, C. M. Heard <[e-mail]> wrote:
> 
> On Sun, Aug 1, 2021 at 2:56 PM Joe Touch wrote:
> > > On Aug 1, 2021, at 2:33 PM, Joseph Touch wrote:
> > > > > On Sun, Aug 1, 2021 at 10:48 AM Joseph Touch wrote:
> > > > > Also, the trailing variant allows per-reassembled options
> > > > > to be arbitrarily long (limited by the reassembled length),
> > > > > rather than requiring them to fit inside a single fragment.
> > > >
> > > >
> > > > If that is the intent, then
> > > > draft-ietf-tsvwg-udp-options-13#section-5.5 needs significant clarification.
> > >
> > > Yes; this is pending.
> >
> > Fwiw I was assuming that field pointed to the start of the trailer
> > options measured from the start of the UDP data (I might have [forgotten]
> > that nuance in the -13 text) If that field points inside this
> > fragment, it can help the split. If not, then the per reassembled
> > options could be split out only after reassembly. But they don’t need
> > to fit in a single fragment.
> 
> I have to say that I was not altogether pleased with what I thought the draft said, but I find this level of complexity to be downright alarming, and I don't see a need for it.

The value in the terminal fragment is just the value that would have been in the original IP length before fragmentation, less the IP and UDP headers.

That’s very simple. 

Whether it can be used to split off the trailing options requires a simple comparison - if FRAG_END > FRAG_OFFSET, then the trailing options are entirely in this fragment. If not, then not.

The fact that per-reassembled datagram options look exactly like legacy options it similar in its simplicity, as is using TLVs for everything. It’s all about fewer different ways to do the same thing.

Joe