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

[Greg Dowd <[e-mail]>]

I think switches have to use store and forward on link speed changes.  In theory maybe fast to slow doesn't have to but slow to fast of course does.  Tal may know more.  


-----Original Message-----
From: ntp [mailto:[e-mail]] On Behalf Of Miroslav Lichvar
Sent: Tuesday, October 31, 2017 8:57 AM
To: Tal Mizrahi <[e-mail]>
Cc: Aanchal Malhotra <[e-mail]>; [e-mail]
Subject: Re: [Ntp] Drafts on interleaved modes and correction field

EXTERNAL EMAIL


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

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