[tsvwg] Re: John Scudder's Discuss on draft-ietf-tsvwg-udp-options-42: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Thanks for your careful reply. I’ve commented in line where warranted. Anything I didn’t comment on is agreed.

—John

On Mar 14, 2025, at 12:10 AM, C. M. Heard <[e-mail]> wrote:

Hello John,

Thank you for your detailed review. Please see suggested resolutions and clarifications below. All proposed changes, if agreed, will be in the next rev.

On Wed, Mar 5, 2025 at 7:00 PM John Scudder via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
John Scudder has entered the following ballot position for
draft-ietf-tsvwg-udp-options-42: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/<https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DjdSDzeDwLgUJVHJ1bzjv2bA5v093p03rj0O-Ukrw7JouJUk6D2hLs_vxOz2tiZELEBJhgvt6Qs$>
 for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/__;!!NEt6yMaO-gk!DjdSDzeDwLgUJVHJ1bzjv2bA5v093p03rj0O-Ukrw7JouJUk6D2hLs_vxOz2tiZELEBJ2zzhatk$>



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document. I found it interesting and for the most part, solidly
written. I have a few comments about spots I found rough, and one discuss point.

## DISCUSS

### Section 11.8, TIME isn't time

I was bamboozled by this section until I followed the breadcrumb you kindly
left pointing to RFC 7323, and learned that 7323 defines the clock "without any
connection to time" (I am not making this up, it's RFC 7323 Section 5.4). Ergo,
TIME has no connection to time. What a world.

I assume you are inheriting this definition; with that assumption, this section
makes sense, without it, it doesn't. If that's what you are doing, I think you
have to either provide the necessary definitions here, or (probably better)
reference RFC 7232 normatively and state what definition(s) you're inheriting,
instead of casually saying "serves a similar purpose".

(I appreciate that to people who live in this world, this was probably too
obvious to bother writing down. I'm here to remind you that to the casual
punter, it's not obvious.)

We will include a note at the beginning of the section about how the section - and the option - interprets time as monotonically increasing everywhere, but at different rates, i.e., relativisically like Lamport clocks, rather than like newtonian wall clocks, i.e., just as TCP uses its timestamps for PAWS (RFC7323):



5.4<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7323*section-5.4__;Iw!!NEt6yMaO-gk!DjdSDzeDwLgUJVHJ1bzjv2bA5v093p03rj0O-Ukrw7JouJUk6D2hLs_vxOz2tiZELEBJCX6lnHM$>.  Timestamp Clock

   It is important to understand that the PAWS algorithm does not
   require clock synchronization between the sender and receiver.  The
   sender's timestamp clock is used as a source of monotonic non-
   decreasing values to stamp the segments.  The receiver treats the
   timestamp value as simply a monotonically non-decreasing serial
   number, without any connection to time.

Please let us know if a pointer to PAWS and this correlation would be useful to include there.

Yes, I think so. It will be only possible to say for sure once I see it in context, but this sounds fine.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## COMMENT

### Section 10, isn't this part of the base spec?

This section is about UDP Options, but includes the paragraph,

   >> The UDP length MUST be at least as large as the UDP header (8)
   and no larger than the IP transport payload. Datagrams with length
   values outside this range MUST be silently dropped as invalid and
   logged.

Isn't that a requirement of the base UDP transport and independent of options?
Why is it specified here?

RFC 768 does not actually say what to do if UDP length is too long. It is stated here to close the gaps around inconsistencies between the two lengths, because these options rely more heavily on their being consistent and resulting in positive values.

### Section 10, language about lengths is muddled

I have a few problems understanding this paragraph:

   >> Receivers supporting UDP options MUST silently ignore unknown
   SAFE options (i.e., in the same way a legacy receiver would ignore
   all UDP options). That includes options whose length does not
   indicate the specified value(s), as long as the length is not
   inherently invalid (i.e., smaller than 2 for the default and 4 for
   the extended formats). Note: a FRAG option with an unknown length
   field SHALL be treated as an unsupported UNSAFE option.

First, what does "whose length does not indicate the specified value(s)" mean?

We can be more clear. We measure option length from the beginning of the option, not after the option and length field. So if an option 203 arrived with length 0, we would say that its length does not include the option’s own *codepoint* (that’s what we meant).

Specifically, what do you mean by "indicate", how does a length "indicate" a
value?

We’ll revise as “options whose length does not point after the length field itself, i.e., such that interpreting the length would imply that the option does not include its own codepoint or length”.

Even in this clearer (to me!) formulation, this requirement conflicts with the later requirement about “impossible” lengths. This one says (my paraphrase) “if the length is too short, silently ignore the option”. To me “silently ignore” implies moving on to process the next option. To move on, you have to know what byte to consume next. This is normally done by consuming whatever the length field says is next, but in this case we’ve just decided that the length field is wrong, so… what to do? Coerce the length to be whatever the minimum would be? So, in the “it was supposed to be at least 2” case, assume it to be 2, and the “it was supposed to be 4” case, assume it to be 4? That seems fraught.

It seems to me your later proposed text that says

   >> Options with impossible option length field values,
   i.e., underruns of the option itself or overruns of the surplus area,
   MUST be treated as an indication of a
   malformed surplus area and all options MUST silently be discarded.

is both safer and simpler: if the length is nuts, give up on option processing completely. I think then, that since your later (“impossible”) text covers this case, you should remove the “That includes options whose length” sentence here.


My best guess is that you mean for a given type code (oh sorry, "kind"),
there will be some specified structure, for which only certain lengths might
apply, e.g. 10 and 12 for FRAG. Do you mean that, again using FRAG as our
example, a length of 11 wouldn't "indicate" something-or-other? (I devolve to
"something-or-other" because I realized I also don't know what you mean by "the
specified values" -- I guess maybe "the specified values" would be 10 and 12.)

See above; it just explains our length includes the option kind and length and we don’t allow lengths that don’t.

If that's what you mean, I think a less opaque way to say it would be something
like, "... options whose length is inconsistent with the values permitted by
the specification of that option".

Sorry, no - this is about jumping over options you don’t know the spec for because they were added after your implementation. It’s just about the 2/4 length case.

Y’know, that being the case, I wonder if there’s merit to saying it that way. It makes it more concrete. (But the revision you proposed above would already work for me.)


Later, we have "a FRAG option with an unknown length field". What does it even
*mean* for the length *field* to be "unknown"? My best guess is you mean
something like "a FRAG option whose length is inconsistent with the values
permitted by this specification, see Section 11.4".

Will fix to “inconsistent with the frag option header length or length of the overall surplus area”.

OK, although,

      Note: a FRAG option with an unknown length
   field SHALL be treated as an unsupported UNSAFE option.

1. An unsupported UNSAFE option tells me to silently drop all options.
2. Your proposed underrun/overrun text I quoted above tells me to silently drop all options.

Therefore, this requirement is redundant with what you’ve already specified and can (should) be deleted entirely.


### Section 10, is this just a roundabout way of saying "drop it"?

   >> Receivers supporting UDP options that receive unsupported options
   in the UNSAFE range MUST terminate all option processing and MUST
   silently drop all UDP options in that datagram. See Section 12 for
   further discussion of UNSAFE options.

OK, we are just dropping the options. But in the previous paragraph, you told
me that any UNSAFE option implies there is no user data in the normal place:

Requires, not implies - see revision below.

   >> When UNSAFE options are present, the UDP user data MUST be empty,
   and any transport payload MUST be contained in a FRAG option (see

When I put these two things together, what I come away with is that if I get an
UNSAFE option I will deliver no data to the user.

It means that UNSAFE options need to arrive with zero UDP user data, i.e., that all the user data is embedded in the FRAG option.

This seems like a bit of a
roundabout way to tell me that. Maybe it's important to use these phrasings,
but even if so, it would be nice to mention to the casual reader what the
implication is.

The above should clarify this; please let us know if not.

I think we are talking about two slightly different things. I did understand what you’ve written above about where the user data goes. My point is that the passage I quoted says an unsupported UNSAFE results in (requires) no processing of options. The implication of this, plus the requirement for where user data goes in the presence of UNSAFE, is that any UNSAFE option will result in the loss of any user data that might have been present in a FRAG option.

You might reply that this is implicit in the rules I’ve cited, and I agree. I’m just musing about whether it’s worth calling it out as a consequence. (It’s OK if you think it isn’t.)


### Section 10, wut

This made my brain hurt:

                                                 This does not prohibit
   future uses of the entire surplus area; space that would have
   occurred after the EOL can be used as a UDP option instead, i.e.,
   rather than using the EOL option and trying to define meaning beyond
   it, define a new option that uses the remaining surplus area as an
   option itself, in conjunction with an assigned UDP option codepoint
   and length to unambiguously indicate the meaning of that area. This
   also does not prohibit options that modify later options (in order
   of appearance within a packet), such as would typically be the case
   for compression (UCMP).

After I read it a few times, I decided (a) I kind of halfway get what you're
saying, but only halfway, (b) it's non-normative anyway, just some notes toward
possible extensions so it's not worth giving myself a migraine over.

Anyway, be aware that to at least this reader, the quoted text doesn't do an
effective job of communicating. I'm sorry I can't suggest a rewrite.

We’ll revise to be more clear. Here’s the summary (to be turned into prose):

- some have concerns that there might be a need to allow use of the surplus area “after the options”
- however, this is just equivalent to the last option indicating “and here’s how to use the rest of the area”
- using an option to indicate this use is more safe because the option provides a check on the overall payload structure length

Makes sense; thanks.


Separately, we’ll talk about option order and why options other than the ones defined at the outset (here) can’t depend on or modify options that come earlier in sequence, but can modify or depend on the content of ones that come after, i.e., to enable single-pass processing except where absolutely necessary (FRAG, OCS) and avoid circular processing dependencies.

OK.


### Section 10, "impossible"

   >> Impossible lengths SHOULD be treated as an indication of a
   malformed surplus area and all options SHOULD silently be discarded.
   This includes lengths that imply a physical impossibility, e.g.,
   smaller than two for conventional options and four for extended
   length options. Lengths other than those expected result in safe
   options being ignored and skipped over, as with any other unknown
   safe option.

First you mention "impossible lengths", which is interestingly vague.

Will revised to

   >> Options with impossible option length field values,
   i.e., underruns of the option itself or overruns of the surplus area,
   MUST be treated as an indication of a
   malformed surplus area and all options MUST silently be discarded.

   >> Unknown options with possibly valid option length field values, i.e., not indicating underruns or overruns,
   are processed as having valid lengths, i.e., skipping over “length” bytes to the next option
   or end of the surplus area, as determined by the surplus area length (computed from the IP and UDP headers).
   Supported options check whether their length is valid for that option as well.

(And we’ll let the RSE decide how to spell and/or hyphenate over/underruns).

These should both be MUSTs - see below. Underruns might be a SHOULD, but it seems simpler to treat it as malformed and move on...

Looks good to me. See also my comment above about the 2/4 and FRAG cases — I think your text here is better, and sufficient to cover those cases, so you should retain this and remove the special-case text.


Then you say these impossible lengths include (which implies "but not limited
to") underruns. I guess the other impossible length would be an overrun (but
then you specify that as a separate case, see later comment). Are there any
other categories you'd lump under "impossible"? Is it... possible... to use
more precise language than "impossible" here?

See above.

I guess the final sentence excludes lengths that are inconsistent with the type
code^H^H^H^H kind's specification as being "impossible", these are treated by
ignoring them, not giving up completely. Isn't this sentence redundant with
(though clearer than!) the paragraph I complained about above? ("language about
lengths is muddled")

Agreed; the same text applies there - impossible lengths

Yeah, so to belabor the point, you should remove that special-case text.


### Section 10, is this also "impossible"?

   >> Option lengths MUST NOT exceed the IP length of the overall IP
   datagram. A receiver MUST drop all options in such a malformed
   packet and the event MAY be logged for diagnostics.

Either this falls under the "impossible" umbrella I just complained about and
is redundant, or I misunderstand "impossible" even worse than I feared.

Yes - that’s an overrun and that’s why we suggest shifting to MUST above.

OK. Any reason not to remove this redundant requirement then? Or if you want to retain it, perhaps restate it without the RFC 2119 keywords, to make it clear you’re just elaborating on a case of an already-stated requirement, e.g. “One case of an ‘impossible length’ as discussed above, is if the option lengths exceed the IP length of the overall IP datagram. In addition to dropping all options as required above, such an event MAY be logged for diagnostics.”

(But I think you can just drop the text — I aspire to the school of “less is better”.)


### Section 11.4, partially reassembled

                                                               UDP
   options that apply to the reassembled datagram are contained in the
   partially reassembled surplus area, as indicated by RDOS.

What's "partially reassembled" mean? I would have thought this should say
something like,

   UDP options that apply to the reassembled datagram are contained in
   the surplus area of the reassembled datagram, as indicated by RDOS.

which is a bit of an unlovely sentence (too much "reassembled datagram") but
anyway, I can make sense of it and I think it says what I understand you to
mean.

Agreed  - to be added in the next rev.

### Section 11.4, I don't get it

I don't understand this:

   >> Users MAY also select the FRAG option to provide limited support
   for UDP options in systems that have access to only the initial
   portion of the data in incoming or outgoing packets

Can't make head or tail of it. Sorry. :-(

The present text is a bit cryptic. We propose changing that paragraph to:

   >> Users MAY use the FRAG option to provide limited support
   for UDP options in systems that have access to only the initial
   portion of the data in incoming or outgoing packets, as such
   systems could potentially access per-fragment options. Such packets
   would, of course, be silently ignored by legacy receivers that do
   not support UDP options.

I still don’t quite get this but it’s probably because I’m not as conversant with the subject matter as your intended audience. Are you talking about a system that can only read N bytes into a packet? So, for example, if my target system can only read 512 bytes into a packet, I can fragment my packets to be only 512 bytes long?

If so, the red herring for me is what’s special about FRAG in this context. I guess maybe it’s that I can use it to get (in my example) a 1500 byte message to such a system by turning it into 3 FRAG packets.


### Section 11.5, known path MTU

   >> MDS does not indicate a known path MTU and thus MUST NOT be used
   to limit transmissions.

That sounds wrong to me. Surely it represents an upper bound on the PMTU and
thus is of some use in limiting transmissions?

What we’re indicating is that the other side CAN test larger values - they might fail, they might get through.

We can clarify this to indicate that such tests MUST involve positive confirmation of success (PLPMTUD) rather than negative (PMTUD).

Additionally, we'll remove the sentence

The value transmitted is based on EMTU_R, the largest IP datagram that can be received (i.e., reassembled at the receiver) [RFC1122].

and say instead that MDS represents the best estimate of the size of the largest IP datagram that the remote end can send WITHOUT requiring fragmentation and reassembly.

So what I missed is that MDS is only a guess and not a fact? (“endpoint _believes_”) It’s kind of weird to me that the endpoint wouldn’t know with certainty what its own MRU is, but OK.

## NITS

### Section 25.1

I suggest,

OLD
   Note that any user application that considers UDP options to affect

NEW
   Note that any user application that considers UDP options to adversely
   affect

Agreed.

Joe and Mike