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

[Tal Mizrahi <[e-mail]>]

Hi Miroslav,

>> 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?

To the best of my knowledge cut-through from a fast link to a slow link is
not possible. Cut-through from a slow link to a fast link is certainly
possible, and of course between ports that have the same link speed.
In the two latter cases the transmission may start before the end of the
reception.

Regards,
Tal.



On Tue, Oct 31, 2017 at 5:57 PM, Miroslav Lichvar <[e-mail]>
wrote:

> 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
>