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

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

On Sun, Aug 1, 2021 at 10:48 AM Joseph Touch wrote:

> 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.
>


If that is the intent, then draft-ietf-tsvwg-udp-options-13#section-5.5
needs significant clarification. What I read there tells me that the
per-reassembled-datagram options must all appear in the terminal fragment,
following the user data. If the terminal fragment user data length is zero,
that does allow for a long options field, but it is limited by the maximum
fragment length, not the reassembled datagram length.


We’ve been down the path of fixed headers before. 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.
>


Indeed we have, but AFAICT a definitive consensus has not been reached.

As you know, recently I have been advocating a fragment format along the
following lines:


                   +--------+--------+--------+--------+
                   |  Source Port    |   Dest. Port    |

                   +--------+--------+--------+--------+
                   |   UDP Len=8     |  UDP Checksum   |

                   +--------+--------+--------+--------+
                   | OCS=2  | LEN=4  | Option Checksum |
                   +--------+--------+--------+--------+
                   |       ... Other Options ...       |
                   +--------+--------+--------+--------+
                   | FRAG=X | LEN=8  |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   |       ... Fragment Data ...       |
                   +--------+--------+--------+--------+


where X is one of two codepoints, depending on whether the fragment is a
terminal or non-terminal fragment.

This would achieve the goal of pushing all user data in self-contained
fragments to the end of the packet and would thereby allow for checksum
offload of encapsulated packets on commonly available hardware. However,
there's one thing that Tom's header would give us that a naked stack of
TLVs would not: it would enable a NIC to perform header-data split without
parsing a long stack of TLVs. We still don't get around the need to loop
through all those TLVs at some point, but that does not have to be handled
in hardware that is not well-suited for it.

In https://mailarchive.ietf.org/arch/msg/tsvwg/XZxL29UA-95ReA72mxv5-kEytK0/
I floated the following variant of Tom's proposal"

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   |        Source port            |      Destination port         | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Base Hdr
   |        UDP Length = 8         |   UDP Header Checksum         | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |        Payload Offset         |  Option+Payload Checksum      |\
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                                                               | |
   ~                           UDP Options                         ~ -Ext Hdr
   |                                                               | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |                                                               |
   ~                         Payload Data                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this case the fixed header just replaces the currently-defined OCS,
occupying the exact same amount of space while using the same algorithm.
And it is neutral as to whether FRAG is defined as in
draft-ietf-tsvwg-udp-options-13, or as in my counterproposal, or in some
other way, as long as FRAG data is contained in the option space.

For the record:

1. I do not think that it is useful to allow an arbitrary UDP option to be
encoded either as a per-fragment or per-datagram option (or perhaps both).
As I have stated previously, that usage should be spelled out in the option
definition. I believe that there also needs to be a better specification of
what the application protocol running on top of UDP will be able to request
of the UDP layer regarding options. This consideration informs how the FRAG
option needs to be designed.

2. I do not agree with the contention that there is any good reason for
reassembled UDP datagrams with options to wind up in the same format as the
wire format for legacy UDP datagrams with an options trailer. That is an
implementation detail, generally invisible to the outside world. In common
existing implementations options and user data generally follow different
paths to get between the user and the protocol stack, and it is not at all
obvious that the machinations to force these two things into the same mold
provide any benefit to the implementation. As a corollary, I see no
compelling reason why the legacy format cannot remain as is, with a fixed
header replacing OCS in the case where UDP Len = 0.

3, I do not agree that consenting endpoints should be disallowed from using
just the legacy format with a trailer, or just the format with UDP Len = 0.
We would not expect this of a fully conforming implementation, but if it is
useful in specific use cases, I can't see the downside in allowing it, no
matter how hard I squint.  Unlike some other limited domain proposals that
have been floated, this is not something that is likely to cause harm to
the general internet if it escapes.

I expect strong disagreement on all these points. It would be nice to hear
from folks who have been silent in this latest round of discussions.

Thanks and regards,

Mike Heard