* Section 9.8: Resolution of discussion on timestamp RTT processing.

[gorryfair]

This topic was raised by Mike Heard

[Mike-Heard]

There were actually two unfortunately intertwined discussions.

One (which I started) about whether there it should be noted that one mathematically straightforward way to avoid zero-valued timestamp values in the TIME option is to take them from a counter that increments modulo 2^32-1 and perform all arithmetic for calculating RTT modulo 2^32-1. Another method is to take the timestamps from a counter that increments modulo 2^32 and simply substitute the next or previous value in sequence (0x00000001 or 0xFFFFFFFF) if the counter value happens to be zero; this will work just fine if the timestamp resolution is not too coarse. BUT, as long at the TIME option has ONLY the TSval and TSecr fields AND is used solely for estimating two-way RTT and not for estimating (say) one-way inter-arrival time, then the choice of scale and modulus is purely an implementation choice, and the spec does not need to spend more words on it. The text in -22 could remain as-is.

The other discussion (started by Sebastian Moeller) was whether the TIME option should be designed instead as something with three response fields instead of one: TS Echo Reply (as now), Local Receive TS, Local Send TS. This would allow for accurate RTT even if responses are delayed, which would be the case if no reply is sent unless there is reverse traffic. This would require that both ends implement the timestamp counter with the same modulus and scale. To the best of my ability to determine, this discussion petered out without a definite resolution. For the proposal, see https://mailarchive.ietf.org/arch/msg/tsvwg/B8QjlsP-deXOFd1PRaoXym7QBsc/

[moeller0]

I have an alternative proposal for the dual timestamp alternative, reserve the top one or two bits for the intended signaling and have the actual timestamp be 31 or 32 bits, that is IMHO leaps and bounds cleaner than using 0 as NaN/signaling codepoint. However as user of delayed timestamps I certainly would prefer the triple timestamp alternative (which could also use the reserve some bits approach*).

The discussion did not really peter out as far as I am concerned, I am still waiting for Joe's response to this. Also I am still interested whether there are any actual users that requested that and what their take on the issue is.

*) ICMP typre13/14 timestamps are already setting precedence for that in that they recommend to use the highest bit to denote whether the timestamp is NOT in milliseconds since midnight UTC...

[Mike-Heard]

Sebastian and I has the following exchange off-line:

I am still interested whether there are any actual users that requested that and what their take on the issue is.

The TIME option first appeared in the draft-touch-tsvwg-udp-options-05 from February 27, 2017, before WG adoption. I don't believe that it appeared at the request of potential users of the UDP options but rather by analogy with the TCP Timestamps option. It would be interesting to hear what Joe has to say about that.

[SM] +1; I think that conceptually TCP timestamps appear as quite obvious reference, yet due to the difference in feed-back fidelity I think that copying TCP timestamps 1:1 might leave some potential 'on the table'?

Indeed, feedback fidelity is not always the same since TCP is always persistently bidirectional, and that is that's not necessarily the case the case for UDP (it depends on the application). I'll add that comment to the tracker.

[jtouch]

Proposals with alternate versions of "exceptions" to time values are only different; there is always the need to differentiate between values (vs non-values) and to handle rollover, so there's no significant savings in any of the alternates proposed, AFAICT.

As to expansion to three or more fields, that seems out of scope. UDP options are intended for use by user applications, not as a replacement for high-precision network instrumentation.

My conclusion is that there is no change needed. Glad to hear a specific argument to the contrary, of course.

[moeller0]

Proposals with alternate versions of "exceptions" to time values are only different; there is always the need to differentiate between values (vs non-values) and to handle rollover, so there's no significant savings in any of the alternates proposed, AFAICT.

I respectfully disagree, some are better, some are worse. e.g. take the two most significant bits and use them to denote "timestamp valid" and "response requested" then you can take what ever 32bit time the local OS gives you and simply set the two bits accordingly. Sure this cost more than a single codepoint, like your proposal, however it is clear and unambiguous... (TCP timestamps use the "out-of-band" ACK bit as validity marker IIRC)

As to expansion to three or more fields, that seems out of scope. UDP options are intended for use by user applications, not as a replacement for high-precision network instrumentation.

Why? TCP timestamps rely on relative frequent ACKing to retain their utility, but for UDP we do not expect that, the three timestamp protocol retains is utility even with low feed-back rates, so IMHO is clearly superior for UDP. And from personal experience, time information is either reasonably precise or useless... but then I would prefer not to waste an UDP option on something with very limited utility. And respectfully for a potentially mostly uni-directional use-case (for which UDP is well suited) RTT information is far less useful than OWD information, so why not go that extra mile and define a timestamp option that allows that?

[jtouch]

If you take the top two bits of time to indicate valid and response requested, you have effectively used 2^31 patterns to represent what I am able in a single pattern. Both require a compare and full 32-bit compares are single opcodes in software. So your method wastes more values and takes longer to compute. That's not a win.

As to requesting a response, UDP doesn't respond - the application does. If you want that behavior, use the application protocol to indicate the need for a response.

Again, please remember that UDP options are features to enable application behavior - not two-way protocols in of themselves. And they're there to provide information about message-to-message round trip times - not to instrument the OS. An application that wants to indicate "time since last received" can override the recommendation of sending its highest received time, but that presumes the application knows how to correlate the request arrival with the independent action of issuing the response.

Joe

[gorryfair]

As an individual only: I'm tempted to think it might be OK to have a simple method in the spec. There is nothing stopping another option being prototyped and experimented with; and then specified by the WG in the future.

[Mike-Heard]

I concur with Gorry. What is now specified is admirably precise in that it specifies what UDP options passes to the upper layer protocol and what is expected from the upper layer protocol in return. Automatic responses that are not explicitly initiated or enabled by the upper layer are not wanted for security reasons. I understand the utility of what Sebastian asks for, but I think that it should be out of scope for this specification. Precise one-way time stamps can be added by subsequent document if there is a demonstrated demand for that capability and if the DOS issues are properly addressed.

[moeller0]

@Gorry, I take it the proposed timestamp options have actually been prototyped and we do have experimental data showing its utility?

@Mike, I am not sure that precision in specification is a sufficient requirement to put something into a standard, necessary and desirable, for sure; but in the end I assume people will use functionality not based on the beauty of the specification alone but based on utility.

That said, I do not expect to be using UDP options in general or UDP timestamps specifically any time soon anyway, so I am not the target audience.

[Mike-Heard]

I do not know of the TIME option having been prototyped, but it is modelled directly after the TCP Timestamp option, which does have demonstrated utility for the intended purpose.

[jtouch]

So can this be closed or is there an issue that remains to be addressed?

[moeller0]

Well, I still maintain that claiming both: 1) UDP is not TCP and there is no guarantee of timely feed-back 2) TCP timestamps requiring timely feed-back are well suited as a UDP option

does not really rhyme all that much. But we have discussed that already, an I clearly failed to convince you. Since this is your draft, from my side go ahead and close this issue. While I think this is going to be a lost opportunity, I also think that all in all UDP options are well thought out and should get ratified quickly so that real-world implementation and testing can begin*.

*) Again, I am convinced that doing such testing before ratification would be a superior approach, but this WG at least does not roll that way, so let's get this thing RFC'd and see what works and what does not work in reality. I am ready to apologize if it turns out that 2-value timestamps are the optimal solution.

[gorryfair]

Closing other versions of timestamps so document can be published - new TS formats could emerge in later new updates after publication