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

[[e-mail]]

See below


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

> Von: Miroslav Lichvar <[e-mail]>
> An: [e-mail]
> 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=[e-mail]>
> 
> 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.

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.

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

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg