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

[Tom Herbert <[e-mail]>]

On Fri, Jul 16, 2021 at 3:45 AM Joseph Touch <[e-mail]> wrote:
>
> Hi, Tom,
>
> > On Jul 15, 2021, at 2:50 PM, Tom Herbert <[e-mail]> wrote:
> >
> > On Thu, Jul 15, 2021 at 2:32 PM Joseph Touch <[e-mail]> 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 I put per-fragment as headers and post-fragment as trailers, I can do the following processing:
>
> Outbound:
>         A- add/process all (safe) per segment options
>         B- if there are any unsafe options or fragmentation is needed for space:
>                 B.1- split as needed
>                 B.2- process per-fragment / unsafe options on the resulting fragments
>         C- transmit
>
> Inbound does the converse.
>
> In both cases, I can simply skip step B if fragmentation isn’t used/needed.
>
> If all the headers come first for fragments - even the per-segment ones, I either need two versions of step A (one for fragments, one for not) or I need to shuffle the trailer to the header between steps A and B.

If I'm reading the draft correctly, it is possible that UDP options
could appear both in the headers and trailers of a packet. If that is
correct, then that means an implementation needs to be able to handle
both headers and trailers within the *same* packet.

>
> —
>
> Your claim that “trailers are ONLY needed…” (emphasis mine) does not consider that “trailer processing IS needed”.
>
> And whenever there are trailers, there are both headers (the current UDP header) and trailers (UDP options), by necessity.
>
> So having two versions of the option location complicates things in the middle of option processing.
>
> The only objection you have raised is that this will hinder processing that’s already hindered. If there’s a slow path here, IMO it ought to be for fragments, not non-fragments.
>
Protocol trailers are the outlier here. There are existing
implementations and common implementation techniques that will not
handle protocol trailers gracefully (header-data split and RX zero
copy are one example). If protocol trailers are required in all cases
of UDP options, then it's likely that there will be a significant
portion of implementations that either won't support UDP options or
will summarily relegate them to a slow path-- the net effect is that
usability oI UDP options is limited and adoptions of UDP options is
hindered. Conversely, if the requirement is narrowed so that protocol
trailers are only required in legacy mode, then UDP options become
feasible at least in non-legacy mode for those implementations that
can't handle trailers and hence that facilitates wider adoption.

Tom

> Joe