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

[Greg Dowd <[e-mail]>]

As I recall, this all works if every device in the network are timestamp correction aware.  Tal, I think you have probably been involved in many discussions of this type, .  I tend to believe that OSI model implies that we should not be too focused on specifying which bit of which symbol is selected.

My recommendation is that we call out something like 802.3bf (?) and provide examples of the asymmetry/implementation issues associated with selections.  The reality is that timestamps are struck and are “fixed up” to be SOH or ETB in hardware anyway.  The current NTP protocol has already defined the “default” as beginning of tx/end of rx historically.

What do you think?

Thanks…Greg





From: ntp [mailto:[e-mail]] On Behalf Of Tal Mizrahi
Sent: Thursday, November 9, 2017 5:12 AM
To: Miroslav Lichvar <[e-mail]>
Cc: Aanchal Malhotra <[e-mail]>; [e-mail]
Subject: Re: [Ntp] Drafts on interleaved modes and correction field

EXTERNAL EMAIL
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]<mailto:[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