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

[Martin Burnicki <[e-mail]>]

Miroslav Lichvar wrote:
> 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.

I fully agree.

> 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.

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

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