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

[Joseph Touch <[e-mail]>]

Hi, Mike,

Trailers make a reassembled packet look *exactly* like one that isn’t reassembled. That has to be handled, regardless.

Having two *different* places for per-packet options, depending on whether they’re reassembled or not, would be the unnecessary complexity.

Besides, we’ve moved the FRAG option to the front of the list so hardware can find it without processing too much of a TLV chain. Your alternative, i.e., of using FRAG to split per-fragment vs post-fragment options, would mean that the FRAG option would *float* into the TLV chain further, complicating and slowing down reassembly.

I think we need to come to terms with the fact that UDP options means trailers. Once you accept that as a given, putting per-packet options at the end is the obvious place.

Joe

> On Jul 30, 2021, at 8:11 PM, C. M. Heard <[e-mail]> wrote:
> 
> On Thu, Jul 15, 2021 at 2:51 PM Tom Herbert wrote:
> > On Thu, Jul 15, 2021 at 2:32 PM Joseph Touch wrote:
> > > And there is no way to avoid trailers for non-fragmented packets.
> > >
> > Right trailers are only needed in that case. In the case of fragment
> > using both headers and trailers simultaneously is unnecessary
> > complexity that provides no benefit. If just headers are used then the
> > system doesn't need to support trailers for that case and header-data
> > split continues to work as expected.
> 
> On Fri, Jul 16, 2021 at 12:12 AM Paul Vixie replied:
> > +1.
> 
> Let me add my voice to this. The specification of FRAG in -13 is 
> unnecessarily complex. We do not need both headers (for per-frag 
> options) and trailers (for per-datagram options). That format, as 
> Tom correctly notes, is an impediment to checksum offload for 
> encapsulated protocols. The generality of allowing any option to 
> be encoded as per-datagram or per-fragment is a level of flexibility 
> that is comparable to the flexibility offered by independently 
> steerable front wheels: it is neither necessary nor safe, as very 
> few options can serve in both capacities, and there are other ways to 
> deal with those.
> 
> Mike Heard