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

[Martin Duke <[e-mail]>]

Hi Mike,

On Thu, Apr 4, 2024 at 2:22 PM C. M. Heard <[e-mail]> wrote:

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

Thanks for the pointer. I'm glad that the WG has already done what I've
asked.


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

It certainly is. But people don't always read the whole document and when I
hear "fragmentation" I automatically think about IP. This is definitely
just a nit, but if you think it prevents confusion, add it.


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

"End of the packet" is a pretty ambiguous phrasing at this point :-). What
I mean is, what if the datagram contains zero payload, a FRAG option, a
series of other options, EOL, some random bytes, and then the frag start?
Is that legal? I gathered that the intent would be that Frag Start was
immediately after EOL, but then there are alignment issues, etc. What's
legal and what's malformed?

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

I agree that the MRDS definition is vague but I don't think MDS is
ambiguous at all. It's just that 3000 is a weird number for a minimum
because it's 2-point-something datagrams assuming a 1500B MTU.


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

I'm concerned about the opposite: if UDP CS != 0, then the normal
processing path is to expect OCS != 0, but the recommendation in (11.4)
means that OCS will be zero! So there's a special path if the packet is
reassembled. Am I mixing this up?


> (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]?
>

I took that text to mean that sending and receiving this option were under
control of the upper layer. I can see that [Fa24] has some useful guidance
here, and maybe it answers my question that it's an upper layer thing, not
a UDP kernel function.

But does anything belong in this draft? Are there any questions to answer
about token selection in general like the ones I proposed? Can there be
collisions where an application uses a DPLPTMUD library and then does its
own REQ/RESP that happens to use the same token? Do we need a UDP API to
say "you used this token recently"?