Subject: [tsvwg] Per-fragment UDP options: implementation support requirements

From: "C. M. Heard" <[email-masked]>
Date: Sun, 27 Mar 2022 07:54:17 -0700

Greetings TSVWG,

In numerous posts to the mailing list and at the mic at IETF 112 I have
expressed opposition to per-fragment UDP options. My opposition has
softened somewhat, but I would still like for us to settle the extent to
which they need to be supported by implementations of UDP options. I would
like to start the discussion by considering the "must-support" options
first, and then move on to the others.

EOL and NOP: these need to be supported on a per-fragment basis in order to
allow the FRAG header to be aligned. They raise no questions about what the
implementation should do with them since they are consumed by the UDP
options engine and are not passed to the upper layer.

APC: by its definition, the Alternate Payload Checksum protects the user
data in an unfragmented or fully reassembled UDP datagram. Since there is
no user data to protect in a UDP fragment, there is nothing for a
per-fragment version of this option to do. Technically, there is a unique
value of the CRC32c that would yield a correct CRC check on an empty
payload -- if I'm not mistaken that value is 0xFFFFFFFF -- and that could
be checked on each fragment, with the failure flags being accumulated (as
we have discussed for AUTH) and passed to the upper layer with the
reassembled datagram. But no matter how hard I squint, I can't see any
value in doing that.

FRAG: needed to support fragmentation (obviously)

MDS, MRDS: I fail to see a use case for these as per-fragment options,
mainly because the Maximum Datagram Size estimate and the Maximum
Reassembled Datagram Size value are unlikely to change fast enough to need
to be sent in every fragment instead of being attached to the reassembled
datagram. Additionally, if they are accumulated as a sequence of values and
passed to the upper layer with the reassembled datagram, the question
arises what the upper layer would do except to use the last value in the
sequence.

REQ, RES: these were added to the specification specifically to support
DLPMTUD probes, which MUST NOT be fragmented. There may be other use cases
for these options, but if there is one that involves attaching them to
individual fragments, I do not see what it is. If I've missed something, I
ask that someone please correct my failure of imagination.

 My conclusion is that only EOL, NOP, and FRAG should be mandatory to
support in UDP fragments, and I advocate adding that to the specification.
 ----

The remainder of this message consists of comments of the remaining options
in the specification.

TIME: it has been stated that this option may be used per datagram to
estimate aggregate delay and may be used per fragment to estimate path RTT.
Based on what I have read in RFC 7323, where the use of the TCP timestamp
option is described, I am exceedingly skeptical that this option can be
used to provide anything like TCP's RTT measurement unless it is built-in
to the UDP layer and is coupled with something like REQ and RES. I'll be
satisfied as long as an implementation can choose to support the
per-datagram version without also being required to support the
per-fragment version.

AUTH, UENC: as has been noted in another thread, these work as per-fragment
options only if they are configured to protect the UDP options, there being
no UDP user data in a UDP fragment. The use case for per-datagram AUTH or
UENC is that they can protect the UDP fragmentation option and any other
per-fragment options. Given that the IP Authentication Header (RFC 4302)
acts only upon reassembled IP datagrams, and that the IP Encapsulating
Security Payload acts only upon the IP payload, these do not seem like
especially strong use cases. On the other hand, almost all of the
processing for these options occurs under the hood anyway, and we seem to
be converging on a cogent way to specify the interface to the upper later.
Subject to a successful conclusion of that discussion, I think I am
satisfied.

EXP/UEXP: the use cases depend on UDP ExID and so the use cases cannot be
predicted, and I have no comments to make.

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 27 Mar 2022 08:03:19 -0700

Mike,

I do not see the utility in restricting “must implement” to frag vs non-frag. Once something is implemented, something useful should be done in either case. If someone wants to turn on APC and use it per-fragment, it both won’t have any utility but also should not generate an error. If the OS wants to warn a user that this isn’t productive, sure - but there’s no reason to complicate the spec this way.

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

> On Mar 27, 2022, at 7:54 AM, C. M. Heard <[email-masked]> wrote:
> 
> Greetings TSVWG,
> 
> In numerous posts to the mailing list and at the mic at IETF 112 I have expressed opposition to per-fragment UDP options. My opposition has softened somewhat, but I would still like for us to settle the extent to which they need to be supported by implementations of UDP options. I would like to start the discussion by considering the "must-support" options first, and then move on to the others.
> 
> EOL and NOP: these need to be supported on a per-fragment basis in order to allow the FRAG header to be aligned. They raise no questions about what the implementation should do with them since they are consumed by the UDP options engine and are not passed to the upper layer.
> 
> APC: by its definition, the Alternate Payload Checksum protects the user data in an unfragmented or fully reassembled UDP datagram. Since there is no user data to protect in a UDP fragment, there is nothing for a per-fragment version of this option to do. Technically, there is a unique value of the CRC32c that would yield a correct CRC check on an empty payload -- if I'm not mistaken that value is 0xFFFFFFFF -- and that could be checked on each fragment, with the failure flags being accumulated (as we have discussed for AUTH) and passed to the upper layer with the reassembled datagram. But no matter how hard I squint, I can't see any value in doing that.
> 
> MDS, MRDS: I fail to see a use case for these as per-fragment options, mainly because the Maximum Datagram Size estimate and the Maximum Reassembled Datagram Size value are unlikely to change fast enough to need to be sent in every fragment instead of being attached to the reassembled datagram. Additionally, if they are accumulated as a sequence of values and passed to the upper layer with the reassembled datagram, the question arises what the upper layer would do except to use the last value in the sequence.
> 
> REQ, RES: these were added to the specification specifically to support DLPMTUD probes, which MUST NOT be fragmented. There may be other use cases for these options, but if there is one that involves attaching them to individual fragments, I do not see what it is. If I've missed something, I ask that someone please correct my failure of imagination.
> 
>  My conclusion is that only EOL, NOP, and FRAG should be mandatory to support in UDP fragments, and I advocate adding that to the specification.
>  ----
> 
> The remainder of this message consists of comments of the remaining options in the specification.
> 
> TIME: it has been stated that this option may be used per datagram to estimate aggregate delay and may be used per fragment to estimate path RTT. Based on what I have read in RFC 7323, where the use of the TCP timestamp option is described, I am exceedingly skeptical that this option can be used to provide anything like TCP's RTT measurement unless it is built-in to the UDP layer and is coupled with something like REQ and RES. I'll be satisfied as long as an implementation can choose to support the per-datagram version without also being required to support the per-fragment version.
> 
> AUTH, UENC: as has been noted in another thread, these work as per-fragment options only if they are configured to protect the UDP options, there being no UDP user data in a UDP fragment. The use case for per-datagram AUTH or UENC is that they can protect the UDP fragmentation option and any other per-fragment options. Given that the IP Authentication Header (RFC 4302) acts only upon reassembled IP datagrams, and that the IP Encapsulating Security Payload acts only upon the IP payload, these do not seem like especially strong use cases. On the other hand, almost all of the processing for these options occurs under the hood anyway, and we seem to be converging on a cogent way to specify the interface to the upper later. Subject to a successful conclusion of that discussion, I think I am satisfied.
> 
> EXP/UEXP: the use cases depend on UDP ExID and so the use cases cannot be predicted, and I have no comments to make.
> 
> Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 27 Mar 2022 08:07:20 -0700

On Sun, Mar 27, 2022 at 8:03 AM Joe Touch wrote:

> I do not see the utility in restricting “must implement” to frag vs
> non-frag. Once something is implemented, something useful should be done in
> either case. If someone wants to turn on APC and use it per-fragment, it
> both won’t have any utility but also should not generate an error. If the
> OS wants to warn a user that this isn’t productive, sure - but there’s no
> reason to complicate the spec this way.
>

Fair enough about APC; it does not add much burden to an implementation and
it's fairly obvious what it should do.

What about the others?

Mike

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 27 Mar 2022 08:16:16 -0700

Again, I keep thinking of this as a user choice. Users can do either unproductive or harmful things if they want.

We should also note that all new options MUST define behavior in both per-frag and per-datagram cases, but I don’t like over thinking this. FRAG inside FRAG is not something that won’t work, e.g., it just won’t end up with user data until the last reassembly level completes, e.g.

Joe

—

> On Mar 27, 2022, at 8:07 AM, C. M. Heard <[email-masked]> wrote:
> 
> Fair enough about APC; it does not add much burden to an implementation and it's fairly obvious what it should do.
> 
> What about the others?
> 
> Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 27 Mar 2022 08:28:28 -0700

Understood, but there is a cost to providing those choices. Requiring
implementations to provide costly things that provide no benefit doesn't
seem like a good tradeoff to me.

I've spoken my piece, and I'll shut up now and let others chime in if they
choose.

Mike

On Sun, Mar 27, 2022 at 8:16 AM Joe Touch wrote:

> Again, I keep thinking of this as a user choice. Users can do either
> unproductive or harmful things if they want.
>
> We should also note that all new options MUST define behavior in both
> per-frag and per-datagram cases, but I don’t like over thinking this. FRAG
> inside FRAG is not something that won’t work, e.g., it just won’t end up
> with user data until the last reassembly level completes, e.g.
>
> Joe
>
> —
> Fair enough about APC; it does not add much burden to an implementation
> and it's fairly obvious what it should do.
>
> What about the others?
>
> Mike
>
>
>