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

[Tal Mizrahi <[e-mail]>]

Hi Miroslav,

Very nice example.
It clarifies your point.

I believe the inconsistency you raised here could be resolved if both the
client and server would measure all timestamps as the time-of-the-first-bit
(both reception and transmission).
If that would be the case, then (using your example):

Client TX timestamp = X
Switch (client->server) correction field = 1500
Server RX timestamp = X+1700

Server TX timestamp = Y
Switch (server->client) correction field = 11000
Client RX timestamp = Y+11200

In this case the client would compute the delay on both directions to be
200 nanoseconds, as desired.
Again this all works only if the client / server use the first bit as the
reference for both TX and RX timestamps.

Cheers,
Tal.


On Thu, Nov 9, 2017 at 11:38 AM, Miroslav Lichvar <[e-mail]>
wrote:

> On Wed, Nov 08, 2017 at 07:32:07PM +0200, Tal Mizrahi wrote:
> > >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?
> >
> > Hmmm... So the switch would have to evaluate the packet length based on
> the
> > Length field in the UDP header, and use that in the correction field
> > computation.
>
> Good point. Using the UDP length field should be simpler and give the
> switch more time to calculate the correction than waiting for the
> end of the received frame.
>
> > It would be significantly easier to implement a correction field
> > computation based on first-bit-in-to-first-bit-out.
>
> I understand that. The question is if it's worth the incompatibility
> that it would create.
>
> > I may be missing something here, but I would argue that if we
> consistently
> > compute the correction based on first-bit-in-to-first-bit-out, the packet
> > transmission times on both directions would cancel out, and would not
> > affect the symmetry of the computation.
>
> Yes, but only if the client, server and all switches with different
> link speeds between them used the beginning of the reception too.
>
> The clients and servers would have to switch between two modes of
> timestamping. One for networks where the correction fields is not
> supported and one for networks where all switches (with different link
> speeds) support it. It's all or nothing.
>
> On the other hand, a correction field based on the end of the
> reception is compatible with timestamping used by existing clients and
> servers, and a gradual replacement of switches in the network does not
> create an asymmetry.
>
> > Can you provide an example in which this hypothesis is wrong?
>
> Ok, let's say there is a server on 100 Mbit link, a client on a 1000
> Mbit link, and a single switch (store-and-forward) between them. The
> propagation delay is 100 nanoseconds on both links and the switch has
> a constant asymmetric delay of 500/1000 nanoseconds. The client sends
> a 1000 bit frame at time X and the server responds with a frame of the
> same length at Y. All timestamping is perfectly accurate.
>
> The intervals of the receptions and transmissions are:
>
> client TX: [X, X+1000]
> switch RX: [X+100, X+1100]
> switch TX: [X+1600, X+11600]
> server RX: [X+1700, X+11700]
> server TX: [Y, Y+10000]
> switch RX: [Y+100, Y+10100]
> switch TX: [Y+11100, Y+12100]
> client RX: [Y+11200, Y+12200]
>
> If the correction field was ignored, the delays of the request and
> response would be 11700 and 12200 nanoseconds respectively. The
> calculated offset would have an error of 250 nanoseconds.
>
> If the switch calculated the corrections from the beginning of the
> receptions, the delays would be 10200 and 1200 nanoseconds. The error
> in the offset would be 4500 nanoseconds.
>
> If the switch calculated the corrections from the end of the
> reception, the delays would be 11200 and 11200 nanoseconds. The offset
> would have no error.
>
> This shows that the switch has to timestamp the same point of the
> frame as the server and client. Otherwise, the correction field may
> actually increase the error in the measured offset.
>
> --
> Miroslav Lichvar
>