Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

[Joseph Touch <[e-mail]>]

> On Jun 14, 2021, at 11:14 AM, C. M. Heard <[e-mail]> wrote:
> 
> On Mon, Jun 14, 2021 at 10:17 AM Joe Touch <[e-mail] <mailto:[e-mail]>> wrote:
> Yes, but we still need the fraglen field in the last frag too.
> 
> No, it is not necessary, if every option precedes the FRAG header.
> 
> See the format I posted this am. 
> 
> I did read it. If I correctly understand what you wrote, there is an underlying ASSUMPTION that options that apply per-fragment need to precede the FRAG header and those that apply to the reassembled datagram have to appear afterward.

Yes, it was explicit that this is the distinction. That’s because, ultimately, we don’t know how people will define future options or apply them.

> To be clear, I do not dispute that such a design will work; it will. What I dispute is that it is necessary.
> 
> In the design that I presented earlier, I also made an implicit assumption that whether an option applies to an individual fragment or to the reassembled datagram can be determined from the Option Kind (or UKind or ExID). Going down the list:

First, you can’t go down a list that includes options to be defined, unless we further fracture the option space into pre/post reassembly.

Second, many of the examples you give as “known” are not:
	NOP can be needed for padding in either place.
	UNSAFE can’t be known in advance
	TIME can be per frag (for path RTT) or per segment (aggregate delay)
	REQ/RES can be either as well.
	AE for sure - it’s a trade between per-fragment safety and per-datagram efficiency

Regarding zero copy, none of this matters if we put the FRAG header up front as I just proposed. What was missing was the pointer to where the FRAG option was; instead, I put the option up front and point to the data in the option. Same number of fields, simpler offload processing.

Joe