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

[Joseph Touch <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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
> 
>