Re: [Last-Call] [Ntp] Last Call: <draft-ietf-ntp-interleaved-modes-04.txt> (NTP Interleaved Modes) to Proposed Standard

[Miroslav Lichvar <[e-mail]>]

On Sun, Apr 11, 2021 at 04:25:08PM -0400, David L. Mills wrote:
> There is a much easier way to do this,  as I proposed in the recent document
> posted for review. See Section 4.3 for explanation.

I think you are referring to
https://www.eecis.udel.edu/~mills/Autokey3.txt

> The way I propose can be used in all protocol modes and does not requre any
> specific configuration or extension fields.  Briefly, the onwire protocol
> operates as usual, except  that the devstamp of the last transmitted packet
> is saved in a state variable.
> In the reply packet, the origin timestamp is replaced by the saved devstamp.

If the origin timestamp in a response contained a transmit timestamp
of a previous response to the same client/peer, how could it pass the
loopback test at the client/peer? It needs to be a timestamp copied
from the request. For compatibility with RFC 5905 it needs to be the
transmit timestamp from the request (aka basic mode).

> The offset and delay are computed as usual. However, the full interleave
> function requires two protocol rounds to develop a full compliment of
> timestamps. There's no need to do anything special, especially not modify
> any other header field in the reply.  This change is compatible with legacy
> versions and rfc 5905.

The linked document doesn't describe the on-wire protocol in enough
detail for me to understand it. I'd like to see an example with few
exchanges showing all timestamps in packets.

If the protocol really is supposed to be compatible with the current
ntp.org implementation, I don't think it could be very different from
the ntp-interleaved-modes draft discussed in this last call.

The compatibility was one of the goals. The main difference to the
ntp.org implementation is that it automatically switches between
processing packets in basic and interleaved mode, which is needed in
some corner cases, e.g. when polling intervals of two peers in a
symmetric association don't match.

-- 
Miroslav Lichvar