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

[Greg Dowd <[e-mail]>]

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?




-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+greg.dowd=[e-mail]] On Behalf Of Miroslav Lichvar
Sent: Monday, August 31, 2015 8:16 AM
To: Tal Mizrahi
Cc: [e-mail]
Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt

EXTERNAL EMAIL


On Mon, Aug 31, 2015 at 02:04:46PM +0000, Tal Mizrahi wrote:
> >With 1 byte for C1/C2 and 8 bytes for D1/D2 in the NTP timestamp 
> >format that would be 18 bytes of data. That would fit in the padding 
> >in the proposed checksum complement field if you were interested in a 
> >more general form of the "timestamp correction" field.
> >
>
> The purpose of the current draft is to make life easier for HW-based timestamping. HW-based timestamping on the client+server side can significantly improve the clock accuracy.
> I agree that on-path support (transparent clocks) can improve the accuracy further, but that is not the purpose of the current draft...

Understood. I was just thinking the checksum complement would be useful for other time stamping corrections too (not just for HW timestamping on the server or the client) and some of the padding could be put to use.

> BTW, speaking of transparent clocks, wouldn't it be simpler to add an extension field with a <correction field>, as done in PTP?

That's basically what I'm proposing :). But in NTP we need two fields, one for the request and one for the reply. The C1 and C2 counters would I think be a useful addition to that.

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