Re: [tsvwg] UDP TIME Option - per segment or per datagram

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

On Wed, Jul 7, 2021 at 9:44 PM Joseph Touch wrote:

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

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