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

[Miroslav Lichvar <[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.

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