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

[Tal Mizrahi <[e-mail]>]

Hi Miroslav,

Please see below.


>> >BTW, is anyone working on the "timestamp correction" extension field
>> >that is mentioned in this draft? I'd be very interested in that.
>>
>> We (at Marvell) have implemented the hardware aspect of this feature, i.e.,
>timestamping an NTP message + updating its checksum complement.
>
>If I understand it correctly the checksum complement extension field makes it
>easier for you to implement hardware timestamping, which puts the
>timestamp closer to the actual time the packet is sent on the wire.
>
>Now, the question is how to record the delays in the packet processing on the
>path between the server and the client, i.e. add support for NTP "transparent
>clocks". Something that could be easily implemented in routers/switches and
>wouldn't require tracking of all client/server connections. One possibility I
>think is an extension field which has four values: C1, D1, C2, D2.
>
>- C1/C2 is counting how many times the D1/D2 value was updated and
>  D1/D2 is the accumulated delay in the processing, all zeroed in the
>  client request
>- NTP-aware devices on the path to the server increment C1 and add
>  their delays between receiving and sending the packet to D1
>- NTP server swaps the C1 and D1 values with C2 and D2 in the
>  extension field
>- NTP-aware devices on the path to the client update C1 and D1
>- the client can use the D1 and D2 values to fix the calculated offset
>  and delay. If C1 and C2 are not equal, the client knows the two
>  paths are different and may discard the sample.
>
>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...
BTW, speaking of transparent clocks, wouldn't it be simpler to add an extension field with a <correction field>, as done in PTP?

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