Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32

["C. M. Heard" <[e-mail]>]

On Tue, Apr 2, 2024 at 2:23 PM Martin Duke wrote:

> Here is a somewhat late individual review of the udp-options draft, since
> I purposely didn't read it when I thought I'd have to review it as an AD
> evaluatoin.
>

Thank you, Martin, for these thoughtful comments. I have some responses
in-line below, made from my perspective as a proponent.


> Major comments:
> - I'm impressed with the overall cleverness and elegance of this solution,
> particularly the use of FRAG to contain unsafe options in a zero-length
> datagram.
>
> - I appreciate the work to make this an end-to-end signal, and that UDP
> has pre-existing limitations in this regard. I also think the use cases are
> probably valuable.
>
> But in 2024, if we want to make rules about what the network can and can't
> do, we enforce it with encryption and authentication. I recognize that
> these were originally in the draft, and were removed for very good reasons.
> But I'm also worried that, if successful:
> - This will attract "helpful" middlebox functions like MSS clamping.
> - This is an attractive nuisance for various path signaling schemes. They
> are going to come here because other avenues (DSCP, IPv6 Extension Headers)
> have been blocked. And that eventually UDP options will be blocked for the
> same reason that those were blocked. I suppose that enough fortitude in
> TSVWG can forestall this happening. Personally, I would strongly encourage
> these efforts to use encapsulation, or any other mechanism, to avoid
> compromise of the E2E channel you are building here.
> - To the extent that new options are "opt-in" by the endpoint, I'm fine
> with it. But if we reach a point where identifying signals are required by
> the network to participate, that's not so great. I'm not sure that this
> architecture has much in the way of safeguards to prevent that outcome.
>
> This isn't really actionable because I genuinely don't know what to do,
> and luckily for me, I don't have to decide anymore. But I ask the
> proponents and the working group to reflect on this a bit more. And we
> should consciously decide, as a community, if path signaling over UDP is a
> thing we support or not.
>

TSVWG went over this ground, to some extent at least, during the initial
discussions of the initial versions of draft-reddy-tsvwg-explcit-signal
(now expired) and draft-kaippallimalil-tsvwg-media-hdr-wireless (still
active). After several threads in which the merits of using UDP options for
host-to-network signaling was discussed (see, e.g., Challenges for host to
network signaling via UDP Options
<https://mailarchive.ietf.org/arch/msg/tsvwg/SpcVd6EB1Zi6FUhhyn2-o6nxuq4/> and
other messages in that thread), I think most in the WG came around to the
position of *not* wanting to see UDP options used for host-to-network
signaling, The chairs are, or course, the folks who can make authoritative
statements, but that was my impression, at least. The current version of
draft-kaippallimalil-tsvwg-media-hdr-wireless does propose to use UDP
options for signaling, but as part of a tunnel encapsulation arrangement,
which does not conflict with the desired E2E nature of UDP options.


> Some minor points:
> (11.4) It might be worth clarifying at the start that fragmentation is
> purely E2E, not something that routers can do.
>

Is that not made clear enough by 16
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-16>.
UDP Options are for Transport, Not Transit?

(11.4) What if Frag. Start is inconsistent with the location of EOL?
>

Do you mean when Frag. Start points past the end of the packet? It was
clear enough to me that this would be considered malformed and discarded,
but maybe that's just me being too familiar with the intent, and not
actually scrutinizing the text.


> (11.4) 2 fragments/3000 bytes as a minimum will work, of course, but it
> seems like an odd number. This seems to be related to the canonical 1500B
> MTU, but that would imply that 2 fragments would be 2926 for IPv4 and 2886
> in IPv6, if my math is correct. (To be clear, I can live with 3000)
>

I had a similar clarification request about what the value of MRDS size
(11.6) means. My assumption is that parameter means the size of the
Original UDP Datagram (or equivalently, the size of the reassembled
datagram) as shown in Figure 12. If that is the case, we would be referring
to the size of the reassembled datagram EXCLUDING the IPv4 or IPV6 headers
but INCLUDING the UDP header and UDP options transmitted over the wire in
the surplus area. The exact numbers are not that important, but a clear
definition is. It may be appropriate to open a Github issue covering these
points.


> (11.4) "the OCS value of the original packet SHOULD be zero if each
> fragment will have a non-zero OCS value"
>
> I don't understand the purpose of this. First, it complicates packet
> processing because the full datagram has to use a different OCS
> verification path if it's reassembled. Second, if the fragment OCSes are
> sufficient, why not simply say that the original packet MUST NOT have an
> OCS option?
>

Actually, the idea was that reassembly could be implemented as a "bump in
the stack" and that the handling of reassembled datagrams would not vary
much from how it's done for datagrams that are not received as fragments.
IPv4 (and under certain circumstances IPv6) allow zero UDP checksum. The
OCS is mandatory when UDP checksum is non-zero and recommended (but not
required) when the UDP checksum is non-zero. So an implementation already
has to deal with datagrams that have UDP CS == 0 but OCS != 0. Given that,
it seems (to me at least) fair to keep this as a SHOULD, as it does not
require any mechanisms that are not otherwise required.

(11.5) "MDS does not indicate a known path MTU and thus MUST NOT be used to
> limit transmissions."
>
> I am not sure what it means "to limit transmissions". Can you elaborate?
> What is the purpose of this if not to provide a hint of datagram size? Just
> to seed PMTUD?
>
> (11.6) "NOPs are not reported to the user, whether used per-datagram or
> per-fragment (as defined in Section 11.4)."
>
> I think this is a cut-and-paste error.
>

Agreed.


> (11.7) Is the token generated by the UDP implementation or the upper
> layer? Is there any guidance on how to choose the token (should it be
> random or monotonically increasing? Is any method OK as long as they don't
> repeat? Given that UDP is connectionless, what would it even mean that it
> doesn't repeat?)
>

It was my understanding -- and maybe I am simply too close to the spec --
that the upper layer, or a library acting on its behalf, chooses the token
value in a REQ option. I see text that says  "Both the REQ and RES are
under the control of these upper layers." Is this not sufficiently clear,
especially after reading the normative reference [Fa24]?

In closing I have a question for the document shepherd: are we going to go
to WG last call on this version, and of so, should Github issues be opened
to cover WGLC comments?

Thanks

Mike Heard