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

[Miroslav Lichvar <[e-mail]>]

On Wed, Nov 01, 2017 at 11:41:26AM +0200, Tal Mizrahi wrote:
> Small correction:
> Slow-to-fast cut-through is *not* possible.
> Fast-to-slow cut-through *is* possible.

Do you know if there are any switches that actually support it? I
suspect the buffering would be a major complication for a relatively
small improvement in the overall latency.

If a switch cut through from a faster link to a slower link, it would
know the length of the packet and could calculate the (negative)
correction before the correction field was transmitted, right? I
assume that the field is in the second half of the packet and the
ratio between the speeds is at least 2:1.

I think the draft can specify that the correction needs to be
calculated from the end of the reception and beginning of the
transmission if the link speeds are different. If the speeds are
equal, it can be any combination of beginning/end of the
reception/transmission, because a symmetric correction will be made in
the opposite direction. The delay will be different, but there won't
be any asymmetry.

Does that make sense?

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

-- 
Miroslav Lichvar