Subject: [tsvwg] Comment on UDP options draft

From: Tom Herbert <[email-masked]>
Date: Mon, 28 Mar 2022 06:15:42 -0700

Hi,

>From the draft:  "Use of the single fragment variant can be helpful in
supporting use  of UNSAFE options without undesirable impact to
receivers that do not support either UDP options or the specific
UNSAFE options."

The term "fragment" implies that the datum is a piece of something
larger, so there is really no such thing as a single fragment that is
complete self contained data-- that's what a packet is. When UDP
length is eight and the packet is not fragmented, which might a common
case in some deployments, all the receiver needs to know is where the
payload starts after the UDP options; the identification, fragment
offset, and where the reassembled surplus area are not needed and
would otherwise be unnecessary overhead.

The UDP options header is currently the two byte OCS, that could
easily be extended with a two byte options length or header length
field to make a four byte header. The length should be in units of
four bytes to ensure that the UDP payload is properly aligned to four
bytes as it always is with standard UDP. If the packet is actually a
fragment then the frag option would still be needed but then it could
be shortened by two bytes. In a non-fragmented packet the overhead
then drops from twelve down to two bytes.

Note that having an explicit header length field this is consistent
with other protocols that have variable length headers such as TCP and
IPv4. This is also important to allow devices to easily skip over a
variable length header to process the next header instead of having to
process a list of TLVs, which is common in firewalls. IMO variable
length headers should always have a header length field.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Mar 2022 11:52:01 -0700

Hi, Tom,

> On Mar 28, 2022, at 6:15 AM, Tom Herbert <[email-masked]> wrote:
> 
> Hi,
> 
> complete self contained data-- that's what a packet is.

IP has this - I’ve called it an “atomic fragment” in RFC 6864. Here it is a fragment with a starting offset of 0 with the 12-byte option format.

The use of a UDP atomic fragment allows use of UNSAFE options without strictly requiring two IP packets be used.
...
> ..
> field to make a four byte header.

We’ve been around that block before. To recap, the info is needed only for fragments to jump over to user data and is already contained in the FRAG option.

It serves no purpose and only adds another field that requires validation for non-fragmented packets, which is expected to be the dominant use case. 

> ...
> with other protocols that have variable length headers

We have options in a *trailer*. The only time this info is needed is when it is a *header*, which is only in fragments.

> such as TCP and

To the extent that we need to indicate the options length, we already do; it is IPlength - UDPlength. Again, adding another field that could be out of sync with those two invites errors.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 28 Mar 2022 12:55:25 -0700

> We’ve been around that block before. To recap, the info is needed only for fragments to jump over to user data and is already contained in the FRAG option.

Joe,

Yes, we have been around this block before. For sending a single
packet with the UNSAFE option the draft requires both headers and
trailers, and there is at least 10 bytes of unnecessary overhead if
just a header format were used. IMO, this design is overly complex for
both the wire overhead and implementation. AFAICT, the rationale for
it is to maintain compatibility with legacy mode where trailers are
required, as opposed to being consistent with nearly every other IETF
protocol that uses headers and *not* trailers. If the others in the WG
think this complexity is justified then I'll be quiet.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Mar 2022 14:44:13 -0700

Hi, Tom,

Without re-opening the issue of the ‘fixed’ header, yes, there are optimizations for ‘atomic fragments’ that could save some space.

E.g.:
- there’s no reason to have both OCS fields; the post-reassembly one could be reconstituted as zero and not checked
- atomic fragments always have a frag offset of 0

So we could have a 6-byte version of the FRAG header:
	KIND(8) LEN(8) FRAG_START (16)
        DGOPTSTART(16)

That saves 6 bytes; omitting OCS in the trailing option area would save another 2, for a total of 8.

No, I don’t think the other 2 are worth saving; the cost of the existence of these fields should be borne by fragment-using packets.

I don’t think that’s horrible, but also don’t know that the benefit is worth the implementation complexity. Others can comment; if so, the 6-byte “atomic frag format’ is easy enough to add.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 28, 2022, at 12:55 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 28 Mar 2022 14:59:29 -0700

Joe,

The issue was never closed.

> - there’s no reason to have both OCS fields; the post-reassembly one could be reconstituted as zero and not checked

Right, there should only be one checksum. As I've said many times, a
checksum per packet is sufficient. We can't easily offload a checksum
that covers a reassembled packet, it is very little benefit.

> KIND(8) LEN(8) FRAG_START (16)
The FRAG header describes a fragment; there's no point in using it if
the packet is not a fragment. Calling packets "atomic fragments"
doesn't solve the problem. IPv6 did this right by making fragmentation
an extension header instead of inflicting every packet with
unnecessary overhead like IPv4 does.

> I don’t think that’s horrible, but also don’t know that the benefit is worth the implementation complexity. Others can comment; if so, the 6-byte “atomic frag format’ is easy enough to add.

I'd like to see the implementation, especially one that shows that
processing both headers and trailers in the same packet is at all
efficient.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Mar 2022 15:27:04 -0700

Hi, Tom,

> On Mar 28, 2022, at 2:59 PM, Tom Herbert <[email-masked]> wrote:
> 

Sept 2021, AFAICT. Please take it up with the WG chairs if you feel otherwise.

> Right, there should only be one checksum.

With fragmentation, there always is; only the per-fragment OCS is non-zero. The per-packet OCS is zero because it serves no additional purpose. Whether we carry that explicitly or hide it to save two bytes is just a compute vs. processing trade. The current description assumes the bytes are actually there to simplify processing.
...
> doesn't solve the problem.

The FRAG header enables us to hide the user data in the surplus area, rather than being in the UDP data field.

That, in turn, allows us to use UNSAFE options - either with packets that are split into multiple fragments or those that are in a single “atomic” fragment.

(Recall that we need to hide that data because we CANNOT allow it to be delivered to a legacy receiver).

> IPv6 did this right by making fragmentation

That’s exactly why it’s an option for UDP too - to not waste space when that capability is not needed.

> processing both headers and trailers in the same packet is at all

We are *allowing* UDP options before and after the user data buried in the option field. For atomic fragments, there is no reason to use both; they make sense as distinct only for multi-packet fragmented packets.

If we don’t want to allow both before/after in atomic, we might save another two bytes somewhere. But again, we’re optimizing at best, and that doesn’t seem useful to focus on.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 29 Mar 2022 05:04:55 -0400

On Mon, Mar 28, 2022, 6:27 PM [email-masked] <[email-masked]>
wrote:

> >> Without re-opening the issue of the ‘fixed’ header, yes, there are
> optimizations for ‘atomic fragments’ that could save some space.
> >>
> >
> > Joe,
> >
> >> - there’s no reason to have both OCS fields; the post-reassembly one
> could be reconstituted as zero and not checked
> >
> With fragmentation, there always is; only the per-fragment OCS is
> non-zero. The per-packet OCS is zero because it serves no additional
> purpose. Whether we carry that explicitly or hide it to save two bytes is
> just a compute vs. processing trade. The current description assumes the
> bytes are actually there to simplify processing.
> ...
> >
> That, in turn, allows us to use UNSAFE options - either with packets that
> are split into multiple fragments or those that are in a single “atomic”
> fragment.
>
> >> No, I don’t think the other 2 are worth saving; the cost of the
> existence of these fields should be borne by fragment-using packets.
> >>
> >> I don’t think that’s horrible, but also don’t know that the benefit is
> worth the implementation complexity. Others can comment; if so, the 6-byte
> “atomic frag format’ is easy enough to add.
> >>
> >
> We are *allowing* UDP options before and after the user data buried in the
> option field.

Joe, please clarify the normative requirements. Does a receiver supporting
UDP options need to be able to process protocol trailers? Is this a MUST, a
SHOULD, or a MAY.

If it's a MUST, then what does that mean for most routers in deployment
that only have a parsing buffer for processing headers and have no
capability to process protocol trailers. Are they just out of luck for
terminating UDP tunnels that might have UDP options?

If it's a SHOULD or a MAY, how does sender know it's peer is able to
process UDP options in headers but possibly not in trailers?

Tom

For atomic fragments, there is no reason to use both; they make sense as
> distinct only for multi-packet fragmented packets.
>
> If we don’t want to allow both before/after in atomic, we might save
> another two bytes somewhere. But again, we’re optimizing at best, and that
> doesn’t seem useful to focus on.
>
> Joe
>
>
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 29 Mar 2022 08:21:51 -0700

Hi, Tom,

> On Mar 29, 2022, at 2:04 AM, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
> On Mon, Mar 28, 2022, 6:27 PM [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Tom,
> 
> > On Mar 28, 2022, at 2:59 PM, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > On Mon, Mar 28, 2022 at 2:44 PM [email-masked] <mailto:[email-masked]>
> > <[email-masked] <mailto:[email-masked]>> wrote:
> ...
> We are *allowing* UDP options before and after the user data buried in the option field.
> 
> Joe, please clarify the normative requirements. Does a receiver supporting UDP options need to be able to process protocol trailers? Is this a MUST, a SHOULD, or a MAY.

UDP options occur in the surplus area, which is a trailer.

Endpoints supporting UDP options must process UDP options.

Thus endpoints supporting UDP options MUST process the surplus area, which is a trailer.

> If it's a MUST, then what does that mean for most routers in deployment that only have a parsing buffer for processing headers and have no capability to process protocol trailers. Are they just out of luck for terminating UDP tunnels that might have UDP options?

Yes. Until we define a new transport type, there’s no way around that.

> If it's a SHOULD or a MAY, how does sender know it's peer is able to process UDP options in headers but possibly not in trailers?

UDP options are always processed as trailers.

Even in FRAGs, the options that occur before the trailer-encapsulated are still a trailer on the (zero-data) packet.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 29 Mar 2022 15:14:24 -0400

On Tue, Mar 29, 2022, 8:21 AM [email-masked] <[email-masked]>
wrote:

> Even in FRAGs, the options that occur before the trailer-encapsulated are
> still a trailer on the (zero-data) packet.
>

Joe,

The surplus areas doesn't define headers or trailers, it's the position of
the protocol relative to payload that does. That's true for all protocols.
Trailers occur after payload data towards the end of the packet. In the
case that UDP length is 8 the protocol that appears before the payload so
they headers (in this case, an implementation would treat UDP options as
such since there are contiguous with the UDP header and all the other
preceding headers).

The practical implication is that there are devices that cannot parse and
process protocol trailers deep in the packet.

So let me restate the question. Does a receiver have to process trailers
that are offset more than 512 bytes in the packet (say a packet with MTU of
1500). Many devices do not have to capability to process trailers that
deep. Such devices obviously cannot support legacy mode, however it's not
clear to me what the requirements are for non legacy mode.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 29 Mar 2022 14:00:24 -0700

Hi, Tom,

> On Mar 29, 2022, at 12:14 PM, Tom Herbert <[email-masked]> wrote:
> 
> So let me restate the question. Does a receiver have to process trailers that are offset more than 512 bytes in the packet (say a packet with MTU of 1500).

Yes - whenever the UDP data is larger than 512B (plus or minus, depending on where you count from), because a packet using only SAFE options always has all the options after the data.

You could say that packets using UNSAFE options that chose to put the options before the data could do otherwise, but then how would they process the data when the data *itself* were inside an option? I.e., in that case, even smaller user data could exceed the limit of 512 (i.e., 512 - sizeof options).

> Many devices do not have to capability to process trailers that deep. Such devices obviously cannot support legacy mode, however it's not clear to me what the requirements are for non legacy mode.

UDP has no “legacy mode”. The options do not vary depending on who implements them. 

We define only “legacy endpoints” as those that do not support UDP options and "option-aware" endpoints as those that do. 

UDP options have a behavior defined for legacy endpoints, which is that they are designed to be silently ignored except to deliver either the original data (if all options are SAFE and no fragmentation is needed) or a packet with no data (if any option is UNSAFE or if reassembly is required).

Joe

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 Mar 2022 07:16:02 -0700

Joe,

Sorry, I still don't see a clear answer to my question. Let me try one
more time: if a device terminating UDP does not have capability to
process protocol trailers, but otherwise has sufficient capabilities
to process protocol headers will it be able to support UDP options?
Please try to answer with a yes or no.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 31 Mar 2022 14:11:35 +0100

> Please try to answer with a yes or no.
I think the answer is "no".

The design places the protocol control information in the area after the 
UDP Datagram. This was an early design decision, and it places the 
options by appending to an existing datagram, although if a device does 
not support this, the options data will not be available. That's the way 
it has been specified.

Gorry