Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Sep 2015 15:03:25 +0200

On Mon, Aug 31, 2015 at 03:43:55PM +0000, Greg Dowd wrote:
> Probably moving further offtopic but why would you need 2?  And why the counters?  The correction field in PTP was originally designed because the hardware couldn't update the timestamps on the fly.  It would post-process and then send a follow-up with the precise timestamp.   NTP supports that  with the interleave mode.  With today's technology, it's at least possible to simply update the actual timestamp in a MAC/PHY.
> 
> However, if we used an extension with a correction field, the receiver would sum the components of the timestamp to calculate the actual receive time.  That could then be stuffed into t2 and no D1 would be in the reply.  

Yes, if the server applied the correction immediately, there would
be no need for a second field. But I don't think that's what we want
to do. The client may want to check the sanity of the corrections
(if they are smaller than the measured delay) or check if they actually
improve the jitter. The support could be horribly broken on some
device on the path and we wouldn't know until the field was turned off.
It would also prevented mixing of authenticated data with
unauthenticated corrections if it was possible to not cover the field
by the MAC.

In PTP the correction field is applied only by the slave too. There is
no need for two correction fields, because there is either only one
measurement per request/response or there are two measurements but only
one correction is needed as in the case of peer delay request/response
(which is also the reason why the pdelay timestamps shouldn't be used
to calculate the offset with a nonzero correction).

> With the counters, it might be interesting to know how many nodes updated the correction field, but I'm not sure what quantitative assessment you could make.  Would you anticipate a dispersion compensation (similar to old stratum calculation) where a fixed error was added per hop?

I was thinking about detecting network asymmetries on the path between
client and server. If C1 and C2 are not equal, the paths were
different and the source could be rejected in the source selection or
have a smaller weight when combining with others.

However, this would only work if there was a different number of
updates in the two directions. I guess it could be improved by using a
checksum instead of counter which all NTP-aware devices would update
with their own (random) ID.

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

---

From: [email-masked]
Date: Tue, 1 Sep 2015 16:36:22 +0200

See below

"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> wrote on 
01.09.2015 15:03:25:

> Von: Miroslav Lichvar <[email-masked]>
> An: [email-masked]
> Datum: 01.09.2015 15:25
> Betreff: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]>
> 
> > Probably moving further offtopic but why would you need 2?  And 
> why the counters?  The correction field in PTP was originally 
> designed because the hardware couldn't update the timestamps on the 
> fly.  It would post-process and then send a follow-up with the 
> precise timestamp.   NTP supports that  with the interleave mode. 
> With today's technology, it's at least possible to simply update the
> actual timestamp in a MAC/PHY.
> > 
> > However, if we used an extension with a correction field, the 
> receiver would sum the components of the timestamp to calculate the 
> actual receive time.  That could then be stuffed into t2 and no D1 
> would be in the reply. 
> 
> > With the counters, it might be interesting to know how many nodes 
> updated the correction field, but I'm not sure what quantitative 
> assessment you could make.  Would you anticipate a dispersion 
> compensation (similar to old stratum calculation) where a fixed 
> error was added per hop?
> 

I understand the intention of these counters. But from my point of view 
they are not sufficient to detect different paths. The problem is that 
that even if C1 equals C2 the paths might be different. So, even with 
equal counters you cannot be sure to only use sources with even paths.

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 7 Sep 2015 10:23:41 +0200

Greg Dowd wrote:
> Probably moving further offtopic but why would you need 2?  And why
> the counters?  The correction field in PTP was originally designed
> because the hardware couldn't update the timestamps on the fly.  It
> would post-process and then send a follow-up with the precise
> timestamp.   NTP supports that  with the interleave mode.

IMO the interleave mode is just a hack.

"Interleaved mode can be used only in NTP symmetric and broadcast 
modes", quoted from
https://www.eecis.udel.edu/~mills/ntp/html/xleave.html

I really like Miroslav's idea. If support for latency compensation is 
introduced then it would be good to not just introduce a first level 
compensation now and another level later, but just provide a way which 
allows for the highest degree of accuracy.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 7 Sep 2015 10:28:12 +0200

> unauthenticated corrections if it was possible to not cover the field

I fully agree.

> have a smaller weight when combining with others.

On the other hand, if the delays in bot directions can be measured 
separately and this is done properly on the involved nodes then it 
shouldn't matter if the request and reply packets go over different routes.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Sep 2015 14:49:42 +0200

On Mon, Sep 07, 2015 at 10:28:12AM +0200, Martin Burnicki wrote:
> separately and this is done properly on the involved nodes then it shouldn't
> matter if the request and reply packets go over different routes.

I think the correction fields are supposed to include only the
processing delays. The NTP-aware devices generally can't know the
network delays between them.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Sep 2015 15:14:50 +0200

On Mon, Sep 07, 2015 at 10:23:41AM +0200, Martin Burnicki wrote:
> "Interleaved mode can be used only in NTP symmetric and broadcast modes",
> quoted from

Yeah, it would be nice if there was a proper "follow-up" extension
that an ordinary client could request from the server. There might be
a problem with traffic amplification, however. If the server is not
required to save the tx timestamp for a later query, there will have
to be two server packets per one client packet. Maybe a larger padding
in the client packet could be required to offset that.

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 8 Sep 2015 09:43:43 +0200

> network delays between them.

OK, you're right. The constant (cable) delays will also differ and can't 
be determined if the routes differ.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Greg Dowd <[email-masked]>
Date: Tue, 8 Sep 2015 15:57:51 +0000

I won't argue about the current state of interleave mode although I think the lack of development effort applied to that mode of operation is more an indication of a lack of interest in this capability in the current ntp market as well as recognition that there are emerging alternatives.   The capability of transferring stratum 1 synchronization in telecom networks using this method was out well before interleave was introduced so there is no question that any high resolution timestamped frame is a good source of frequency and time but the ecosystem may not be able to use it.  Really the main issue with the interleave mode is the need to recognize that it is in use, similar to the issue discussed with the leap "smear" mode.

As for alternatives, this draft is exactly that type of alternative as I'm sure you're already aware.  You can just update the timestamp field and use the checksum trailer to fixup the frame.  Again, a technique used for years, just a matter of whether the market requires that function in this type of application.  

Are you thinking that a discrete field is easier to implement?  Or that the clients would use intelligence to analyze the stability/accuracy/authenticity of the correction creators and include/disclude their correction?  If so, then a chain of extensions may be a better methodology.  One current issue with the PTP correction field is the "bucket" nature that it aggregates all intermediate corrections.

The nice thing is that the way the protocol is evolving, all possibilities are available while maintaining backward compatibility.  There are actually some nice things about using NTP such as the timestamp demarq can be seen as inherently more precise than the PTP definition since it uses the y.1731 beginning of xmit/end of receipt which corrects for network bandwidth steps.

-----Original Message-----
From: Martin Burnicki [mailto:[email-masked]] 
Sent: Monday, September 07, 2015 1:24 AM
To: Greg Dowd; Miroslav Lichvar; Tal Mizrahi
Cc: [email-masked]
Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt

EXTERNAL EMAIL

"Interleaved mode can be used only in NTP symmetric and broadcast modes", quoted from https://www.eecis.udel.edu/~mills/ntp/html/xleave.html

I really like Miroslav's idea. If support for latency compensation is introduced then it would be good to not just introduce a first level compensation now and another level later, but just provide a way which allows for the highest degree of accuracy.

Martin
--
Martin Burnicki

Senior Software Engineer

Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Sep 2015 08:35:29 +0200

>>> Greg Dowd <[email-masked]> schrieb am 08.09.2015 um 17:57 in Nachricht
<[email-masked]>:
> I won't argue about the current state of interleave mode although I think the 
> lack of development effort applied to that mode of operation is more an 
> indication of a lack of interest in this capability in the current ntp market 
> as well as recognition that there are emerging alternatives.   The capability 

I'd be careful with such statements: Occasionally it takes some time to make people aware of new features, and most scenarios have a mix of old an new NTP releases (for a variety of reasons). I'm not commenting on the value of the specific interleave mode feature, but just in general.

> of transferring stratum 1 synchronization in telecom networks using this 
> method was out well before interleave was introduced so there is no question 
> that any high resolution timestamped frame is a good source of frequency and 
> time but the ecosystem may not be able to use it.  Really the main issue with 
> the interleave mode is the need to recognize that it is in use, similar to 
> the issue discussed with the leap "smear" mode.
> 
[...]

Regards,
Ulrich

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 9 Sep 2015 17:20:09 +0200

Greg Dowd wrote:
> I won't argue about the current state of interleave mode although I
> think the lack of development effort applied to that mode of
> operation is more an indication of a lack of interest in this
> capability in the current ntp market as well as recognition that
> there are emerging alternatives.

The problem I see with NTP's interleave mode is mainly because it 
doesn't work with normal client/server associations, so it doesn't help 
normal clients of an NTP server to increase the possible accuracy.

> The capability of transferring
> stratum 1 synchronization in telecom networks using this method was
> out well before interleave was introduced so there is no question
> that any high resolution timestamped frame is a good source of
> frequency and time but the ecosystem may not be able to use it.
> Really the main issue with the interleave mode is the need to
> recognize that it is in use, similar to the issue discussed with the
> leap "smear" mode.

Yes, also the leap "smear" is a hack which can help to avoid problems 
with lleap seconds if operating systems would just step the system time 
back.

> As for alternatives, this draft is exactly that type of alternative
> as I'm sure you're already aware.  You can just update the timestamp
> field and use the checksum trailer to fixup the frame.  Again, a
> technique used for years, just a matter of whether the market
> requires that function in this type of application.

Some time ago we have made tests with NTP and hardware timestamping of 
NTP packets, and we found that (as expected) NTP can yield the same 
level of accuracy as PTP in this case.

However, the main problem was that unlike PTP, the NTP protocol doesn't 
know "followup" packets which the client can use to compensate some 
processing delays on the server.

So IMO interleave mode is just a workaround for those missing followup 
packets. Possible alternatives were an (incompatible) extension of the 
protocol to support followup messages, or putting some correction into 
an extension field of an NTP packet "on the fly" when the packet is sent.

As we've seen in some earlier email this would not even be sufficient to 
determine and compensate constant delays introduced by different routes 
or cables lenghts, so eventually also delay request messages like used 
by PTP would be helpful.

Unfortunately a huge drawback I see is missing hardware support for NTP. 
PTP has been asking for hardware timestamping support in NICs and 
switches for a long time, and now there are PTP-capable devices available.

On the other hand, normal NTP would not even be able to yield the same 
level of accuracy in practice because there are no NIC chips or switches 
which can timestamp NTP packets, so the protocol will still suffer from 
varying latencies if NTP servers and clients support harware timestamping.

> Are you thinking that a discrete field is easier to implement?  Or
> that the clients would use intelligence to analyze the
> stability/accuracy/authenticity of the correction creators and
> include/disclude their correction?

Yes, I agree with Miroslav that it would at least allow clients to do 
some plausibility checks.

> If so, then a chain of extensions
> may be a better methodology.  One current issue with the PTP
> correction field is the "bucket" nature that it aggregates all
> intermediate corrections.

Agreed. But IMO it would be even worse if the "original" time stamps 
would be modified with corrections, and thus ended up in a "bucket", 
where eventually the client wouldn't even be able to distinguish if the 
time stamps have been modified on their way, or not.

> The nice thing is that the way the protocol is evolving, all
> possibilities are available while maintaining backward compatibility.
> There are actually some nice things about using NTP such as the
> timestamp demarq can be seen as inherently more precise than the PTP
> definition since it uses the y.1731 beginning of xmit/end of receipt
> which corrects for network bandwidth steps.

Agreed.

Martin
-- 
Martin Burnicki

Senior Software Engineer