Re: [Ntp] Drafts on interleaved modes and correction field

[Miroslav Lichvar <[e-mail]>]

On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote:
> >With NTP there is generally no HW support, so clients and servers
> >should use trailer RX timestamps and preamble TX timestamps to avoid
> >an asymmetric delay with different link speeds. The following document
> >explains the issue nicely.
> >
> >https://www.eecis.udel.edu/~mills/stamp.html
> >
> >Do you think it will be difficult to implement? If the link speed and
> >length of the packet is known, the timestamp can be transposed.
> 
> The link speed is not necessarily known to the end points.

I meant that the devices which are supposed to modify the correction
field know the link speed and can transpose preamble timestamps if
necessary.

The end points don't need to know the link speed on the path. Just the
speed of their own link if they need to transpose their timestamps.

> Furthermore, the
> link speed may change several times along the path.

In such case we want the correction to still be symmetric, right?

> Maybe I am missing something, but it appears that when measuring
> last-bit-in-to-first-bit-out we are ignoring the packet reception time; it
> seems to make sense to include the packet reception time in the residence
> time.

For PTP yes, but not for NTP. The reception time is included in the
network delay as measured by the client, which will be symmetric as
long as no device on the path includes in the correction the
transmission time or reception time.

> Moreover, we never know which nodes along the path use store-and-forward,
> and which nodes use cut-through. In cut-through forwarding the packet
> transmission may start before the last bit is received, so it certainly
> makes more sense to measure the first-bit-in-to-first-bit-out.

That's a good point. With cut-through switching the correction would
be negative and generally couldn't be determined in time to be put in
the packet as the length is unknown. Are there any switches that can
cut-through from a faster link to slower link?

Maybe it would make sense to allow corrections from preamble RX
timestamps when the link speeds are equal.

> >The reason for a separate transmit correction is to support the
> >interleaved modes. The receive correction might not be necessary. If
> >you have a better use for the 2 octets, I think it could be dropped
> >and included in the origin correction instead.
> 
> So it looks like two correction fields would suffice: one for the forward
> direction, and one for the reverse direction. Right?

I think it's three fields if we want both support the interleaved
modes and allow the client to check the delay correction in both
directions. Where would be the transmit correction included if there
were only two fields?

-- 
Miroslav Lichvar