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

[Joseph Touch <[e-mail]>]

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

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.

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

Joe