Re: [Ntp] comments on draft-mlichvar-ntp-ntpv5-03 / Extension fields

[Doug Arnold <[e-mail]>]

Just to be clear: PTP does not require that all switches are PTP capable.  The ITU-T G.8265.1 and G.8275.2 profiles explicitly assume that there is no or only partial timing support in the network path.  Financial data centers often do not need on-path support since their networks are designed for minimum latency.

Practically speaking, in long network paths, it would take only one busy router with no timing capability to render the correction field irrelevant. The Correction proposed for ntpv5 would probably be most useful for site local use cases, at least at first.  But if it became common for switch and router vendors to implement this feature, then WAN timing would gradually become more precise.

Doug

From: ntp <[e-mail]> on behalf of Miroslav Lichvar <[e-mail]>
Date: Thursday, December 2, 2021 at 3:59 AM
To: [e-mail] <[e-mail]>
Subject: Re: [Ntp] comments on draft-mlichvar-ntp-ntpv5-03 / Extension fields
On Wed, Dec 01, 2021 at 10:26:11PM -0600, Dan Drown wrote:
> Quoting Miroslav Lichvar <[e-mail]>:
> > I have no idea if anyone is actually willing to implement the
> > correction field. In any case, it will still be more difficult to
> > implement than the PTP correction field as NTP works with timestamps
> > corresponding to the end of the reception instead of beginning.
>
> Wouldn't the middle boxes just need to measure queue latency from RX(first
> byte) to TX(first byte)? The gist you linked had the correction factor just
> adding latency in the request packet and subtracting latency in the response
> packet to result in the asymmetric latency that the client can use as a
> correction.

That assumes the correction field is supported on all network devices
between the server and client, or at least that all network links have
the same speed and the packet length doesn't change (e.g. due to
adding and removing VLAN tags). If that is not the case, the
correction will have an error due to the asymmetric link speed or
length.

In the NTPv5 draft this specific case is mentioned, but in general it
is required that the correction works with the end of the reception to
support networks where not all devices support the correction field.

This is in contrast to PTP which requires the support everywhere. That
is ok as PTP was specifically designed for full hardware support. But
in NTP I think it would be nice if switches in a network could be
upgraded only one at a time without breaking the assumptions.

--
Miroslav Lichvar

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp