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

[Joseph Touch <[e-mail]>]

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.

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