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

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Jan 2019 13:07:07 +0100

On Fri, Dec 14, 2018 at 01:03:29PM -0800, Harlan Stenn wrote:
> - 18ns corresponds to a precision of about -26.  While that's pretty
> special,

I'm not sure if that is really special. Modern CPUs have a time-stamp
counter, which can be read in few tens of nanoseconds. The precision
of a typical hardware clock on NIC is same or even better.

> I remain curious about how long the delay is between pulling
> the transmit stamp and the packet going out over the wire.

It should be similar to receiving a packet, i.e. few microseconds.
Depending on the OS/driver, with a very fast NTP server close to the
client, it is actually possible to receive the response before the
transmit timestamp of the request.

> If the basic
> precision of the system clock is only -19, we're not going to do better
> than 2 microseconds.  For situations like this, I'm really curious if
> we'll even see any benefit to client/server interleave mode.

I think an improvement in accuracy should be possible even with such a
clock.

> - I'd like to explore a "follow up" message as an alternative.

A protocol using follow up messages could certainly be specified, but
it would enable traffic amplification. That's probably the last thing
we want to add to the client/server mode. There are few sentences
about this in the latest version of the draft.

In any case, such a protocol would be very different from the
interleaved modes and should be specified separately. It could work in
all three modes: client/server, symmetric, broadcast.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Jan 2019 13:20:28 +0100

On Wed, Dec 19, 2018 at 12:40:26PM -0500, Daniel Franke wrote:
> Existing RFCs do not adequately ensure that existing implementations
> that are not aware of interleaved mode will never send a request of
> this form.

You mean the RFCs don't explicitly say that clients should not send a
request with an origin timestamp equal to the server's receive
timestamp? Is that necessary when the RFCs describe what the origin
field is set to, i.e. the server's transmit timestamp, or zero if it
is a SNTP client or a client following the data minimization?

Even if we ignore the RFCs, I think realistically the only reason for
a client to be inadvertently sending requests in the interleaved mode
would be a bug. IIRC that's what happened in NTPsec when it dropped
support for the interleaved mode, but was sending all requests in the
interleaved mode and no longer being able to process the responses.
(I suspect this might be the origin of your concern.)

> If a client fully implements RFC 5905 and is there is no
> other request in the same scope, then it's okay: it will instead set
> its request's origin timestamp to the server's previous reply's
> transmit timestamp, and this proposal correctly requires that the
> receive and transmit timestamps in the reply not be equal. However,
> this breaks down as soon as there are multiple clients in the same
> scope (e.g., both behind the same NAT), especially if some of them are
> non-conforming.

I think you said this several times, but I still don't understand.

> At minimum, servers must then ensure that they never
> send a transmit timestamp that matches *any* receive timestamp sent to
> the same scope.

That's what the draft says (or at least tries to).

> Even then, non-conforming clients can break conforming
> clients within their scope by sending colliding timestamps.

How exactly? Can you please give a specific example?

> These failures may prove rare in practice, but there is no excuse for
> taking the risk given that there is a much cleaner alternative: do not
> alter any existing semantics, and instead put interleaved timestamps
> into an extension field.

If there are failures, how would putting the timestamps in an
extension field prevent them? Again, a specific example might help me
to understand the issue.

The trouble with an extension field is that it would make the packet
longer, which would increase the NTP delay. So, a clock filter might
prefer measurements in the basic mode over interleaved mode. That's
not good. I think packets in the basic and interleaved mode need to be
of the same length.

> Finally, one unrelated nit: [I-D.ietf-ntp-data-minimization] is listed
> as an informative reference, but it's referenced in sentences that use
> RFC 2119 language, so it needs to be normative.

Ok. I didn't know that.

Thanks for your comments.

-- 
Miroslav Lichvar