Subject: Re: [tsvwg] UDP Options - per segment or per datagram

From: Joseph Touch <[email-masked]>
Date: Wed, 7 Jul 2021 21:44:44 -0700

Hi, Mike,

I’ll try to take this in one shot, but it might be useful to followup in separate threads.

See below…

Joe

> On Jun 26, 2021, at 4:53 PM, C. M. Heard <[email-masked]> wrote:
> 
> On Mon, Jun 14, 2021 at 11:51 AM Joseph Touch  wrote: 
> On Mon, Jun 14, 2021 at 11:14 AM C. M. Heard wrote:
> On Mon, Jun 14, 2021 at 10:17 AM Joe Touch wrote:
> Yes, but we still need the fraglen field in the last frag too.
> 
> No, it is not necessary, if every option precedes the FRAG header.
> 
> See the format I posted this am. 
> 
> I did read it. If I correctly understand what you wrote, there is an underlying ASSUMPTION that options that apply per-fragment need to precede the FRAG header and those that apply to the reassembled datagram have to appear afterward. To be clear, I do not dispute that such a design will work; it will. What I dispute is that it is necessary.
> 
> In the design that I presented earlier, I also made an implicit assumption that whether an option applies to an individual fragment or to the reassembled datagram can be determined from the Option Kind (or UKind or ExID). Going down the list:
> 
> EOL - not applicable (FRAG consumes all trailing data)
> NOP - per fragment
> OCS - per fragment
> ACS - per datagram
> FRAG  - per fragment (obviously)
> UNSAFE - depends on Ukind
> TIME - per datagram
> AE - per fragment (see below)
> REQ, RES - per datagram
> EXP - depends on UDP ExID

I should also note that the classification above is not accurate; at a minimum, NOP can be needed for alignment both in fragments and the reassembled datagram. AE can be used per fragment or one the datagram for different reasons (e.g., per fragment is safer but per datagram could be much more efficient).

> 
> First, you can’t go down a list that includes options to be defined, unless we further fracture the option space into pre/post reassembly.
> 
> What I had in mind was that the definition of each option that the higher layer could request would specify whether it applied to the entire reassembled datagram (thus appearing only in the terminal fragment) or to each individual fragment (thus appearing in each). Options that are produced and consumed entirely at the transport layer would be per-fragment.

Agreed.

> Logically, this is similar to the IPv4 Copied on Fragmentation flag, which is specified for each IPv4 option, but with two important differences:

There is no such “flag". That is a value expressed in an IANA table, but is not a bit in the option KIND or anywhere else in the header. 

Interestingly, all items in the IANA table for IPv4 options indicate copy or no copy, but no options there have dual use (as NOP) or alternate use (as AE).

> 1. Since there is no such thing as in-flight UDP fragmentation -- it occurs only at the source -- there is no need for the fragmentation engine to worry about options it does not understand; the higher layer simply cannot request these options.

Agreed.

> 2. In IPv4 EOL and NOP are not copied on fragmentation, but they also cannot be explicitly requested by the higher layer. They exist solely for the convenience of the layer where they are used. On transmit, they are inserted as needed; on receive, they are consumed. These options can appear in any fragment, but they do not make their way to the higher layer layer with the payload of the received datagram.

Agreed.

> In the cases -- rare, IMO -- where either behavior would be appropriate, it can be distinguished by Option Kind or UKind.

I disagree; again, as with IPv4, there may be limitations to how each option is used, but it should not be encoded in the kind itself. 

> Second, many of the examples you give as “known” are not:
> 	NOP can be needed for padding in either place.
> 	UNSAFE can’t be known in advance
> 	TIME can be per frag (for path RTT) or per segment (aggregate delay)
> 	REQ/RES can be either as well.
> 	AE for sure - it’s a trade between per-fragment safety and per-datagram efficiency
> 
> I think I explained NOP and EOL. I already said that the behavior of any UNSAFE options would depend on UKIND, i.e., the definition of the particular unsafe option would state whether it applies per-datagram or per-fragment.
> 
> If TIME can be requested by the upper layer, what is the meaning if the option is requested for a datagram that gets split into multiple fragments, and the option is replicated in every fragment? I can see the per-fragment argument but only when the option is produced and consumed at the UDP layer -- as is the case for the corresponding TCP option (which appears on every segment if it is negotiated). If it's intended to be produced and consumed by the higher layer, it should be per-datagram.  

Time for fragmented packets can be a sequence of values or (depending on whether the API might support this) a range (high/low). That information can be useful to the higher layer in setting parameters of UDP, e.g., how long to keep fragments before discard. Or it could be used within the UDP layer for that sort of tuning automatically.

> The REQ and RES options exist for the benefit of DPLPMTUD and are intended to be sent on a PLPMTU Probe Packet, which itself must not be further fragmented (the probe packet will not serve its purpose if it is fragmented to make it get to its destination). Ideally, these options are used on packets with padding only and no user data; such packets would be generated and consumed entirely within the transport layer or a shim. As they are not subject to fragmentation, they can be considered complete datagrams.

You assume these are not UDP fragmented; I do not. DPLPMTUD could be used to determine ways to avoid IP fragmentation but that doesn’t mean it prohibits the use of UDP fragmentation. All that is required is that the probes are not *IP* fragmented.

> In addition, it seems to me that there is little or no value in taking a REQ option from the user and replicating it on every fragment of a datagram that needs to be fragmented; this causes duplicate REQ tokens. Gorry, any thoughts? (*)

I don’t see UDP as replicating options without direction from the application layer. This isn’t like IP where there was never intended to be such control. For UDP, we should assume that options are included per fragment or per datagram *at the discretion of the upper layer*.

> AE (now AUTH and ENCR, as of -13) can protect  (AUTH) or depend on (ENCR) all the options, if so configured. Certainly in that case it needs to be per segment. It's possible to specify per-datagram versions -- possibly including only per-datagram options, in some normalized form after reassembly -- but this seriously complicates the specification. Do you really want to do that?

Yes - because users might not want the overhead of the per-message ’startup’ and ‘wind-down’ costs associated with most cryptographic algorithms.

> (*) As an aside I see that draft-fairhurst-tsvwg-udp-options-dplpmtud-04 allows one packet contain RES options for multiple REQ datagrams; this currently is not allowed in draft-ietf-tsvwg-udp-options-13:
> 
>    >> Except for NOP, each option SHOULD NOT occur more than once in a
>    single UDP datagram. If an option other than NOP occurs more than
>    once, a receiver MUST interpret only the first instance of that
>    option and MUST ignore all others.
> 
> This is an inconsistency that needs to be resolved.

Yes - I’ll add that to the list of pending updates.

> Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 30 Jul 2021 16:06:33 -0700

> I’ll try to take this in one shot, but it might be useful to followup in

I am following up in separate threads as suggested. This one is for the
TIME option.

On Jun 26, 2021, at 4:53 PM, C. M. Heard wrote:
>
>
> If TIME can be requested by the upper layer, what is the meaning if the
> option is requested for a datagram that gets split into multiple fragments,
> and the option is replicated in every fragment? I can see the per-fragment
> argument but only when the option is produced and consumed at the UDP layer
> -- as is the case for the corresponding TCP option (which appears on every
> segment if it is negotiated). If it's intended to be produced and consumed
> by the higher layer, it should be per-datagram.
>
>
> Time for fragmented packets can be a sequence of values or (depending on
> whether the API might support this) a range (high/low). That information
> can be useful to the higher layer in setting parameters of UDP, e.g., how
> long to keep fragments before discard. Or it could be used within the UDP
> layer for that sort of tuning automatically.
>

In order to get a better understanding of how this would be used I read RFC
1323, which describes the TCP Timestamps Option (TSopt), on which this is
modelled. A couple of things jumped out at me:

1. TSecr is not valid in TCP unless the ACK bit is set in the segment that
carries it:

         The Timestamp Echo Reply field (TSecr) is only valid if the ACK
         bit is set in the TCP header; if it is valid, it echos a times-
         tamp value that was sent by the remote TCP in the TSval field
         of a Timestamps option.  When TSecr is not valid, its value
         must be zero.  The TSecr value will generally be from the most
         recent Timestamp option that was received; however, there are
         exceptions that are explained below.

2. RFC 1232 Section 3.4 provides specific and detailed rules on which
timestamp to echo if more than one is outstanding. The rules are highly
dependent on TCP state.

UDP, of course, has no defined state, and no defined ACK bit, though
stateful protocols with acknowledgments can be defined on top of UCP.  That
suggests to me that the use of TIME -- including which segments carry valid
TSecr values -- would necessarily be dependent on the protocol running on
top of UDP. In other words, all use of this option must be in the hands of
the protocol running on top of UDP, and would depend on the characteristics
of that protocol, including on which messages TSecr is valid.

In my view, if the UDP options spec provides a fragmentation and reassembly
capability, it would be a grievous error to provide visibility to what
happens to individual UDP fragments to the protocol running on top of UDP
-- just as IP does not provide visibility to what happens to individual IP
fragments to the protocol running on top of IP.

That would imply that TIME is a per-datagram option.

Additionally, while it is fair to require that TSecr is zero on datagrams
where it is invalid by the rules of the protocol running on top of UDP, it
seems IMO an unnecessary complication in the usage of the option to reserve
the value zero to indicate an invalid TSecr. That isn't done in RFC 1323
("when TSecr is not valid, its value must be zero" does not imply "when the
TSecr value is zero, it is not valid").

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 30 Jul 2021 17:05:27 -0700

REQ/REs options.

On Jun 26, 2021, at 4:53 PM, C. M. Heard wrote:
>
> The REQ and RES options exist for the benefit of DPLPMTUD and are intended
> to be sent on a PLPMTU Probe Packet, which itself must not be further
> fragmented (the probe packet will not serve its purpose if it is fragmented
> to make it get to its destination). Ideally, these options are used on
> packets with padding only and no user data; such packets would be generated
> and consumed entirely within the transport layer or a shim. As they are not
> subject to fragmentation, they can be considered complete datagrams.
>
>
> You assume these are not UDP fragmented; I do not. DPLPMTUD could be used
> to determine ways to avoid IP fragmentation but that doesn’t mean it
> prohibits the use of UDP fragmentation. All that is required is that the
> probes are not *IP* fragmented.
>

I want to hear what the authors of
draft-fairhurst-tsvwg-udp-options-dplpmtud have to say about this, but I
don't see a use case for sending dplpmtud probe packets that use UDP
fragmentation. Indeed, that seems to be a completely useless and
unnecessary complication.

> In addition, it seems to me that there is little or no value in taking a
> REQ option from the user and replicating it on every fragment of a datagram
> that needs to be fragmented; this causes duplicate REQ tokens. Gorry, any
> thoughts? (*)
>
>
> I don’t see UDP as replicating options without direction from the
> application layer. This isn’t like IP where there was never intended to be
> such control. For UDP, we should assume that options are included per
> fragment or per datagram *at the discretion of the upper layer*.
>

What is the reason and benefit of providing that level of control and
responsibility? How will the application use the information on responses
to UD{ fragments?

I am reminded of the words of one of my mentors, who described such an
excess of flexibility as "independently steerable front wheels".

We do not need that. We need this spec to be as simple as possible and
unambiguous to implement. Making UDP fragments visible to the protocol
running on top of UDP without a clear reason to do so is a clear violation
of those principles.

Mike Heard

---

From: Joseph Touch <[email-masked]>
Date: Fri, 30 Jul 2021 17:18:06 -0700

Hi,, Mike,

As you note, UDP isn’t IP; it need not be constrained the way IP is. Although we don’t expect users visibility or control into the details of IP, there’s no reason to make that assumption for UDP - quite the opposite.

I agree that TIME may or may not make sense per fragment, but there *is* a sensible behavior that can be defined - i.e., to return the list of times to the user and let them decide what is done in response. 

Unless there is clearly no meaning, I see no reason to restrict any option’s use a-priori.

Joe

> On Jul 30, 2021, at 4:06 PM, C. M. Heard <[email-masked]> wrote:
> 
> I am following up in separate threads as suggested. This one is for the TIME option.
> 
> In order to get a better understanding of how this would be used I read RFC 1323, which describes the TCP Timestamps Option (TSopt), on which this is modelled. A couple of things jumped out at me:
> 
> 1. TSecr is not valid in TCP unless the ACK bit is set in the segment that carries it: 
> 
> 2. RFC 1232 Section 3.4 provides specific and detailed rules on which timestamp to echo if more than one is outstanding. The rules are highly dependent on TCP state.
> 
> UDP, of course, has no defined state, and no defined ACK bit, though stateful protocols with acknowledgments can be defined on top of UCP.  That suggests to me that the use of TIME -- including which segments carry valid TSecr values -- would necessarily be dependent on the protocol running on top of UDP. In other words, all use of this option must be in the hands of the protocol running on top of UDP, and would depend on the characteristics of that protocol, including on which messages TSecr is valid.
> 
> In my view, if the UDP options spec provides a fragmentation and reassembly capability, it would be a grievous error to provide visibility to what happens to individual UDP fragments to the protocol running on top of UDP -- just as IP does not provide visibility to what happens to individual IP fragments to the protocol running on top of IP.
> 
> Additionally, while it is fair to require that TSecr is zero on datagrams where it is invalid by the rules of the protocol running on top of UDP, it seems IMO an unnecessary complication in the usage of the option to reserve the value zero to indicate an invalid TSecr. That isn't done in RFC 1323 ("when TSecr is not valid, its value must be zero" does not imply "when the TSecr value is zero, it is not valid").
> 
> Mike Heard
> 
>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 30 Jul 2021 17:20:59 -0700

Hi, Mike,

Although I agree with the general principle that we should keep things simple, IMO that’s also on the user. If they want to use any option per-fragment, it’s on them if that over complicates their work. AFACIT, these options are largely opaque at the UDP layer - they don’t authomatically do anything unless it’s defined - as per Gorry’s draft. It’s up to him to decide if there’s a limit to his API and algorithms that use REQ/RES; others can do otherwise.

Again, UDP is all about the U.

Joe

> On Jul 30, 2021, at 5:05 PM, C. M. Heard <[email-masked]> wrote:
> 
> I am following up in separate threads as suggested. This one is for the REQ/REs options.
> 
> I want to hear what the authors of draft-fairhurst-tsvwg-udp-options-dplpmtud have to say about this, but I don't see a use case for sending dplpmtud probe packets that use UDP fragmentation. Indeed, that seems to be a completely useless and unnecessary complication.
> 
>  
> What is the reason and benefit of providing that level of control and responsibility? How will the application use the information on responses to UD{ fragments?
> 
> I am reminded of the words of one of my mentors, who described such an excess of flexibility as "independently steerable front wheels".
> 
> We do not need that. We need this spec to be as simple as possible and unambiguous to implement. Making UDP fragments visible to the protocol running on top of UDP without a clear reason to do so is a clear violation of those principles.
> 
> Mike Heard