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

[Martin Burnicki <[e-mail]>]

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

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Fax: [phone]

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
[e-mail]
http://lists.ntp.org/listinfo/ntpwg