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

[Tal Mizrahi <[e-mail]>]

Small correction:
Slow-to-fast cut-through is *not* possible.
Fast-to-slow cut-through *is* possible.

I had it reversed in my previous mail. :)

Regards,
Tal.

On Wed, Nov 1, 2017 at 8:48 AM, Tal Mizrahi <[e-mail]>
wrote:

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