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

[Miroslav Lichvar <[e-mail]>]

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