Subject: [ntpwg] Wish for NTPv5: asymmetry of the network delay

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 22 Oct 2015 10:47:54 +0200

Hi!

I have a wish for NTPv5, but I don't know if it's possible to do:

1) Measure the asymmetry of the network delay (per server/peer)

2) Report that asymmetry (maybe filtered statistically)

3) Allow automatic or manual compensation for the asymmetry.

I'm aware that any measured delay could be actually a clock offset, but maybe some clever algorithm can distinguish both.

Regards,
Ulrich

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Anil Kumar <[email-masked]>
Date: Thu, 22 Oct 2015 10:40:34 +0000

I wish for NTPv5 in case of decoupling transport protocol. Decoupling NTP
timestamps and other extended TLVs. If possible phase synchronization.

With Regard
Anil S N

On Thu, Oct 22, 2015, 3:22 PM Ulrich Windl <
[email-masked]> wrote:

> I'm aware that any measured delay could be actually a clock offset, but
> maybe some clever algorithm can distinguish both.
>
> Regards,
> Ulrich
>
>

---

From: Hal Murray <[email-masked]>
Date: Thu, 22 Oct 2015 04:00:59 -0700

> 1) Measure the asymmetry of the network delay (per server/peer)
...
> maybe some clever algorithm can distinguish both. 

I don't think you can measure the delay unless you already know the time at 
both ends.

You can reject some obvious bad samples if you have good samples to compare 
with.  That catches things like queuing delays if they don't last too long.  
If you have asymmetric routing, the question is how long does it last.

Check out the huffpuff parameter.

You can see routing changes if you turn on rawstats and plot the data.  You 
will see is jumps in round trip time lasting hours to days.  If you also plot 
the offset (assuming symmetric routing) you can easily see if the assumption 
is valid.  Often it indicates that the additional routing delay is all on one 
side.

-- 
These are my opinions.  I hate spam.

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 22 Oct 2015 23:06:59 +0200

Hi Hal,

> I don't think you can measure the delay unless you already know the time at

Yes and no.

You have three unknowns, the actual delay from A to B, the actual delay 
from B to A and the time difference between A and B.
You make two observations, the apparent delay for a message from A to B 
and the apparent delay from B to A.
Three unknowns and two equations does not generally solve itself.

Knowing one of them resolves the rest of the equations.

PTPv2 uses hints from PTP-supporting hardware to remove their 
contribution to asymmetry.

Other protocols uses a high number of packets and then selecting the 
time-stamps from those with apparent low delay, to reduce the bias of 
packet forwarding delays, which may or may not be the majority of the 
asymmetry.

Reformulating the request for means to reduce asymmetry would make more 
sense.

> If you have asymmetric routing, the question is how long does it last.

Well, even with relatively high loads, you occasionally can get low 
delay packets through.

> Check out the huffpuff parameter.

Yes. NTPs problem is however that it has been designed to use a very low 
packet rate, and in order to be efficient, it needs a higher packet rate 
in order to be able to throw away more time-stamps.

Another aspect is that the reason for NTP to use a low packet rate is in 
order for a single server to answer many clients. It would be better if 
clients where asking servers closer to them and that those servers can 
ask upwards with a higher rate instead. This way, a shorter distance 
between each server and client, and a higher packet rate will both 
reduce the amount of possible asymmetry over each link, but better 
statistics for each branch to throw away more of the bad time-stamps, 
while maintaining the same rate towards the top server... which today 
can handle more packets per second anyway.

We could do things pretty different if we dare to.

There is some interesting papers to read if you search for minTDEV, MAFE 
among others.

> is valid.  Often it indicates that the additional routing delay is all on one

Cheers,
Magnus