Re: [Ntp] Comments on Miroslav's NTP v5 proposal.

[Miroslav Lichvar <[e-mail]>]

On Mon, Nov 30, 2020 at 09:31:26PM +0000, Doug Arnold wrote:
> One more thing on the correction field.  In my scheme only the client offset is corrected.  The delay is still the real round trip delay, rather than some kind of corrected delay.  I was thinking that the real round trip delay is what matters. Is that right?  

No, the delay needs to be corrected to not break weighting and
filtering of the measurements.

>     Regarding the datatypes:  What do you think of time16, time32, and timestamp64.  It makes a distinction between the first and the format used for timestamps.

Ok, maybe. What do others think?

>     Regarding the correction field: I think that the easiest route to adoption by manufacturers of switches and routers is to make it work just like PTP.  That is one field that corresponds to the dwell time, difference between the egress and ingress timestamps.  In my scheme the switches and routers do not even have to determine if the message is a request or a response.

PTP uses two correction fields and it corrects the delay too. They are
just in separate messages. Sync messages have their own correction and
delay requests have their own correction. In NTP the two measurements
happen in a single exchange, so there need to be two fields in one
message. For the switch it does not matter, it will always update only
one field as the fields are swapped on the server.

>     Regarding interleaved mode:  I think that this is only important for niche applications that need high precision.  These are generally in smaller networks, where servers saving state for each client is less of an issue.  Note also that several manufacturers make ntp servers with one-step hardware timestamping, where neither follow_up messages not interleaved mode are needed.

That's a good point. However, I suspect one-step timestamping would
difficult to implement with authentication.

-- 
Miroslav Lichvar