Re: [Ntp] WGLC: draft-ietf-ntp-interleaved-modes

[Miroslav Lichvar <[e-mail]>]

I have some data with respect to the concern that existing clients may
be unintentionally sending requests in the interleaved mode and not
being able to process the responses. There was a discussion about this
on the last interim meeting, but some people who I think would be
interested and may had useful comments were not present, so I'm
repeating it here.

I have analyzed NTP traffic on three public servers from the
pool.ntp.org project, in three different countries (all included also
in the global zone). They were capturing the traffic for about two
weeks. In total it was about 3.5 billion requests. I've excluded my
own clients and testing tools using the interleaved mode from the
analysis.

About 20% of all requests had a non-zero origin timestamp.

About 0.0002% of all requests were in the interleaved mode (receive
timestamp different from transmit timestamp and origin timestamp equal
to one of the server's previous 50 million receive timestamps).

All clients that sent an interleaved request seemed to use the mode
consistently. There was not a single interleaved request generated by
chance.

There were two clients sending interleaved requests, but not able to
process an interleaved response, i.e. it was always followed by a
request using the origin timestamp from the last basic response. Both
clients were identified as the older NTPsec version which had an
incompletely removed implementation of the interleaved mode.

So, it doesn't look like there is a client that accidentally
implemented requests in the interleaved mode on its own, e.g. by not
strictly following the existing RFCs.

The question is what, if anything, should be done about clients that
have or will have an incomplete or buggy implementation of the
interleaved mode. That could happen at any time and it doesn't matter
how the protocol is designed, if it's using an extension field, or
not.

One option is to change the draft to require the servers to drop the
pair of receive and transmit timestamps once it has been used to
generate a response. That will force the protocol to fall back to the
basic mode when the client is not able to process the response. In the
worst case this would effectively cause a 50% packet loss, but the
client would still be able to synchronize to the basic responses.

The drawback is that the protocol will fall back to the basic mode
when the response is really lost, when the server could still have
responded with the same timestamp to the following request and the
client was able to process it.

Thoughts?

-- 
Miroslav Lichvar