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

[Joseph Touch <[e-mail]>]

> On Aug 1, 2021, at 1:32 PM, C. M. Heard <[e-mail]> wrote:
> 
> 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.

Yes; this is pending.

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

What we have so far are three of us largely debating the issues, agree.

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

With that version, the DMA can’t happen until the whole TLV is parsed.

> 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 haven’t proposed a long stack of TLVs; the current text puts the FRAG field right after the optional OCS, specifically for this reason,

HOWEVER, I keep hearing that IPv6 “got it right”, yet a long stack of TLVs is exactly what it uses for frag and reassy too - not a fixed header.

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

But the format above doesn’t make sense for non-FRAGs because the payload comes earlier; if it were used, it would waste space when OCS isn’t used in addition to wasting space on the payload offset.

We’ve discussed using fixed headers before, but the issue is that UDP, like IPv6 (the most modern example of options), does have a fixed header and then a set of TLVS. There’s no pointer like you assume above to where the options end and data starts.

So if hardware supports frag/reassy for IPv6, why wouldn’t it work for UDP?

Joe