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

[Tom Herbert <[e-mail]>]

On Sat, Jul 17, 2021 at 7:56 PM Joseph Touch <[e-mail]> wrote:
>
>
>
> > On Jul 17, 2021, at 6:05 PM, Tom Herbert <[e-mail]> wrote:
> >
> > On Sat, Jul 17, 2021 at 4:06 PM Joe Touch <[e-mail]> wrote:
> >>
> >>
> >>
> >>> On Jul 17, 2021, at 2:58 PM, Tom Herbert <[e-mail]> wrote:
> >>>
> >>> 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.
> >>
> >> That is always the case for non-fragmented packets - the only mode that supports transparent use of options that don’t change the payload data with legacy receivers.
> >
> > Perhaps I'm not reading it correctly, but it seems like in legacy mode
> > all options are in trailers in the surplus area. In the last fragment
> > case, the packet may look like
> > UDP-header/UDP-options-per-packet/Frag-data-UDP-options-for-reassembled-packets.
> > So in that case, there are UDP options in both headers and trailers in
> > the same packet.
>
> Again, that happens for legacy packets too - the existing UDP header is in the front and options are in the trailer.
>
> > If that's true, then a device that can't handle
> > protocol headers can't handle the case where there are trailing
> > options in the last fragment.
>
> I can’t parse this in a way that makes sense. A device that can’t handle protocol headers can’t do UDP’s existing header.

> A device that can’t ALSO handle trailers can’t process UDP options for non-fragment packets.

Joe,

To be specific, a device that can't handle protocol trailers would not
be able to process UDP options in the trailing surplus area.
Non-legacy mode, when UDP length is zero, can carry non-fragmented
packets. In non-legacy mode, such a device would be able to process
UDP options if they were contained in the headers of the packet.

Consider that there are whole classes of devices that terminate UDP
but will not be able to process protocol trailers. For instance many
routers that terminate VXLAN can only append headers for TX and can
only process headers in a limited parsing buffer on RX (these same
routers probably cannot compute the UDP checksum either which was the
motivation for RFC6935 and RFC6936). Can the benefits of UDP options
be enjoyed in an environment with such devices?

There will be deployments, say limited domains, that don't need or
want support for legacy mode and have devices that can't support
protocol trailers anyway. For example, consider a user who wants to
use UDP options but is only interested in fragmentation. Since the
fragment TLV lives in the headers this deployment scenario is
technically viable since protocol trailers are not involved. Is the
user allowed to use UDP options in this case?  If the answer is yes
then what is the correct behavior if someone misconfigures a node to
start sending options in protocol trailers? Does a receiver need to
drop the packet, ignore the trailer options, etc.?

Elaborating on this scenario, suppose a payload compression TLV is
developed. SImilar to fragmentation, this is a type of data transform
so the option must be processed and hence cannot be used in legacy
mode. Again, it seems like the user can safely configure this for
non-fragmented packets in non-legacy mode by doing per packet
compression where the compression TLV lives in the headers. But what
if the user wants to use fragmentation and compression at the same
time (i.e. because compression is more efficient over larger blocks of
data)? Per the current draft, I don't believe they would be able to do
this, since the compression TLV would need to be in protocol trailers
which their devices couldn't process. But if the compression TLV were
to appear in the headers then our user would be able to do this.

Eliminating the reliance on protocol trailers in non-legacy mode would
also reduce packet overhead. In the last fragment TLV, there are two
pointers: one to the start of the fragment data and one to the start
of the protocol trailer. If there are no protocol trailers then the
latter pointer is unneeded and can be removed saving two bytes and
making the format of the two fragment TLVs identical. Furthermore,
since all we need to know the length of the UDP options this could be
indicated by a single byte in a fixed header (perhaps with a
multiplier of four to allow up to 1020 bytes of options like in
draft-herbert-udp-space-hdr). This would reduce the size of the
fragment TLV by two bytes byte with a net savings of one byte, but
more significantly, when non-legacy mode is be used to carry a
non-fragmented packet, like in the compression use case described
above, a fragment TLV is not needed at all and so the packet overhead
is reduced from twelve bytes to one byte.

Furthermore, placing the options that apply to the reassembled packet
in the first fragment instead of the last allows some nice
implementation optimizations. For instance, with the aforementioned
compression TLV we could decompress packets as they are received
instead of waiting to get the final fragment before starting. Also,
there's the possibility that the final fragment might contain a
mandatory option that the receiver doesn't understand and so the
reassembled packet needs to be dropped; if the option is in the first
fragment instead of the last, the action to drop the packet can be
detected much earlier so fragment data received in subsequent packets
does not need to be stored which avoids unnecessarily tying up memory
resources in reassembly with data that is never used for anything.

Tom

>
> > If those options were in the headers
> > instead, then it could handle that case. Or maybe the idea is that a
> > receiver can ignore options after the last fragment data since they
> > are in trailers like legacy mode?
>
> The idea is that, after reassembly, UDP processing *continues exactly as it would for a non-reassembled packet.
>
> Those trailing options apply to the WHOLE reassembled packet, not just the final fragment.
>
> Joe
>
>