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

[Tom Herbert <[e-mail]>]

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

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.
draft-herbert-udp-space-hdr-00 defines such a fixed header. In that
format, the options length is expressed in one byte with a multiplier
of four, so that would allow up to 1020 bytes. I know that the does
set a limit, however consider that (AFAIK) no one has ever proposed an
option or set of options in datapath protocol that would come close
needing that much space, the length of the options is already limited
by MTU where 1020 bytes already exceeds the Min MTU for IPv4 and is a
significant portion of IPv6 Min MTU, and also we know that allowing
unlimited options creates problems in itself (i.e. why we need to
limit IPv6 HbH and Dest Ops like in draft-herbert-6man-eh-limits).

Tom

>
> The code cost is small; this way an implementation could decide when it can use a single DMA or no. The only hazard is that the transmitter decides - but for the UDP tunnel case, given both sides already need configuration, it should be simple enough to encourage transmitters to use the preferred case.
>
> ----
>
> We could consider “Frag. End” to really just point to the start of the per-reassembled datagram options, so let’s instead call that field “Reassembled datagram option start”, or RDOS for short. Let’s assume there’s a “RDOE” (end pointer) as well, which we’ll compute.
>
> If so, then we could allow those options to be either before the start of the fragment (where RDOS < Frag Start) or at the end of the packet (where RDOS > Frag Start).
>
> If we allow that, then the code needs a condition to decide where the end of the packet is:
>
> if (RDOS < frag start)
> then  // single DMA case
> frag end = IP packet end
> RDOE = frag start - 1
> else  // receive processing same as for non-terminals
> frag end = RDOS-1
> RDOE = IP packet end
>
> At that point, the per-reassembled options are from RDOS to RDOE and the fragment is from frag start to frag end.
>
> ----
>
>
> On Jul 31, 2021, at 2:08 PM, Joseph Touch <[e-mail]> wrote:
>
> Right - per fragment options would be OK, not per reassembled datagram.
>
> Would that suffice?
>
> Joe
>
> On Jul 31, 2021, at 1:42 PM, Tom Herbert <[e-mail]> wrote:
>
> On Sat, Jul 31, 2021 at 12:42 PM Joe Touch <[e-mail]> wrote:
>
>
>
>
> On Jul 31, 2021, at 11:58 AM, Tom Herbert <[e-mail]> wrote:
>
> There’s no way that endpoint can ensure it never sees non-fragment UDP options, so it cannot support UDP options.
>
> For a tunnel, use of UDP options would just be another configuration
> parameter at the end points; we don't need negotiation to send
> non-legacy packets. If there's a mismatch in endpoint configuration
> then the operator simply detects it and fixes it like any other tunnel
> configuration problem.
>
>
> Ok, the simply don’t set any per packet options and I’ll be fine.
>
> I think you might mean the other way around. Per packet options are
> already defined in the draft to be in the headers, including the
> fragment option, so there's no issue concerning protocol trailers.
> There would only be a problem from options that apply to the
> reassembled packet which would be in trailers of the last fragment.
>
> Tom
>
> Joe
>
>
>
>