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

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

On Mon, Jun 14, 2021 at 9:32 AM Gorry Fairhurst <[e-mail]>
wrote:

> > An obvious feature we'd want is NIC hardware to do UDP options
> > fragementation and reassembly, analogous to existing UDP Fragmentation
> > Offload (UFO) which performs IP fragmentation of UDP packets. The
> > impediment with supporting this is that hardware devices would need to
> > perform protocol processing on trailers as opposed to headers. Nearly
> > all hardware devices, including switches and NICs, are optimized to
> > process protocol headers and in modern devices they are quite
> > programmable in that regard. However, they typically rely on a parsing
> > buffer that holds the first N bytes of the packet and assume that all
> > the protocol headers lie within that. They wouldn't process data after
> > that header in the fast path at least, and almost certainly would have
> > capability to process protocol headers at that end of a large packet.
> > I am doubtful we'll ever see hardware support for trailer protocols,
> > and hence it's unlikely we'd see accelerations for UDP options like we
> > have for TCP.
> >
> > Tom
>
> OK.... Is there any way that we could design to enable this?


> I'm "fishing" for ideas because I know you've talked about the various
> offload methods.
>
> So for options in the trailer, this is clearly an impediment.
>
> For UDP-Opt fragmentation, I understand there is no standard UDP payload,
>
> .... only an option containing a fragment, so the Fragment information
> would actually be in the" first N bytes of the packet".
>
> So, what do you think  could be most likely helpful to enable fastpath
> accelleration for the fragments?


The proposal that I floated a few days ago in
https://mailarchive.ietf.org/arch/msg/tsvwg/N1fmoBxQ5iOL5X7o34oVSA8Ayvw/
would move all of the fragment data to the end of the packet, with UDP
header and UDP options preceding. The very last option would be FRAG
itself, and it would consume all trailing data.

Joe was displeased by replacing the length byte by a More Fragments flag
and suggested instead using two Option Kind codepoints to distinguish
terminal and non-terminal fragments. That would be fine with me and would
not change the proposal in any fundamental way.

Mike Heard