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

[Tom Herbert <[e-mail]>]

On Sun, Aug 1, 2021 at 10:48 AM Joseph Touch <[e-mail]> wrote:
>
>
>
> > On Aug 1, 2021, at 10:03 AM, Tom Herbert <[e-mail]> wrote:
> >
> > On Sat, Jul 31, 2021 at 2:17 PM Joseph Touch <[e-mail]> wrote:
> >>
> >> FWIW, there’s another option here, which could be considered unnecessarily complex if there’s no need for per-reassembled datagram options for most UDP tunnels….
> >>
> >> ----
> >>
> >> Right now, the terminal fragment has a header as follows:
> >>
> >>                   +--------+--------+--------+--------+
> >>                   | Kind=4 | Len=12 |   Frag. Start   |
> >>                   +--------+--------+--------+--------+
> >>                   |           Identification          |
> >>                   +--------+--------+--------+--------+
> >>                   |  Frag. Offset   |    Frag. End    |
> >>                   +--------+--------+--------+--------+
> >>
> >>                Figure 12   UDP terminal FRAG option format
> >>
> >> As to whether to put the per-reassembled options before or after the terminal fragment, we could let the user decide (again, consistent with the idea of UDP), as follows.
> >
> > Joe,
> >
> > I suggest that the per-reassembled options be in headers in the first
> > fragment. This would work by specifying that options preceding the
> > fragment option are per-packet, options following the fragment option
> > in the first fragment apply to reassembled packets, and options
> > following a fragment option in non-first fragment would be ignored.
>
> Again, that means that the FRAG option itself would float far inside the TLV list, which complicates DMA.
>
I don't understand your concerns. The method I am describing is
functionally equivalent to how fragmentation is done in IPv6. There is
a fragment extension header that "floats" inside the IPv6 header
chain, options that are before the fragment extension header are
applied per packet and those after the extension header are applied to
the reassembled packet. This is no issue with DMA since there are no
trailers and we can use header-data split with fragments.

> Also, the trailing variant allows per-reassembled options to be arbitrarily long (limited by the reassembled length), rather than requiring them to fit inside a single fragment.
>
> That’s a key reason for using trailing options - no limit on length, even with fragmentation. That’s why we need a version that allows that, otherwise the options would be limited to what will fit in exactly one option.
>
Deployment experience has shown arbitrarily long lists of TLVs in a
datapath protocol is more a problem than a benefit. Implementations
have a lot of trouble with these and to date the only use case for
this is DoS attack.

> > So, in this manner fragments don't have any protocol trailers and
> > therefore Frag. End isn't needed and can be removed from the fragment
> > option saving two bytes (the end of the fragment would coincide with
> > the end of the packet).
>
> But then we need at least one byte back for the one bit to indicate last-fragment.
>
> > As I mentioned previously, there are other
> > advantages to placing the options that apply to the reassembled packet
> > in the first fragment instead of the last.
>
> We need to keep a way to allow arbitrary option lengths;

Why? Can you provide a *specific* example of an option or set of
options that needs hundreds of bytes of options?

> every fixed header approach to that ends up hitting a limit that later needs a workaround (see the work on extending the TCP header).
>
> > In the tunnel case we'd also cases where UDP options might be sent
> > that are not fragments, however we still need to know where the
> > payload begins. In the fragment option this is the Frag. Start field,
> > but sending a whole fragment option just to convey these two bytes of
> > information would be way overkill. IMO a better approach is to
> > indicate the length of the options in a fixed header preceding the
> > options since the information is always required.
>
> We’ve been down the path of fixed headers before.

And we've been down the path of protocols that allow arbitrarily long
lists of TLVs. See IPv6 Hop-by-Hop options and Destination options.
There is about no deployment of these and a major reason is that
implementations efficiently implement necessary support.

> It wastes space for some uses to conserve it for others. E.g., in tunnel cases where UDP CS==0, it would waste space for OCS when not needed.

Somehow the whole purpose of having a checksum in protocol is lost in
this draft. The point of a checksum is that it's an integrity check of
the protocol. Frankly, the requirements described in the draft seem
more concerned with making sure the checksum is set properly to
packets to get through some misbehaving routers on the Internet. The
argument that UDP Options doesn't need a checksum is disingenuous
given that UDP doesn't have options in the first place so making the
checksum required in UDP to cover options; however the other major
transport protocol of IETF, namely TCP, has a checksum that always
covers TCP options. Similarly, the argument that the IPV6 UDP tunnels
can have a zero checksum is disingenuous. If you read RFC6935 and
RFC6936 you'll find that the conditions for which a zero checksum can
be safely set are quite narrow. One of those conditions is if the
encapsulated protocol has an integrity check of its own.

IMO, a checksum should always be required over the surplus area. The
value we get from an integrity far exceeds the overhead which is a
whole two bytes. It's pointless to spend time quibbling rather than a
fixed overhead of two bytes is better or worse than a protocol that
saves those two bytes in some cases, but increases overhead to three
bytes.

Tom


>I
> Joe
>