>> > The main reasoning here was, I believe, that an inherent solution
>would be
>> > easier to tailor to a time synchronization protocol's special
>needs,
>> > particularly for the additional delays caused by the
>cryptographic
>> > operations on time-sensitive packets to be small (and ideally
>> > symmetrical).
>> >
>>
>> OK, that's interesting.
>> Can you please elaborate on the symmetrical requirement?
>
>I assume that he's talking about the time between getting T1 and
>sending out the packet, and getting T3 and sending it out would
>need about the same delay.

For the record: yes, this is what I was talking about.

>
>I also assume that to be able to get a very accurate results. But
>if that's the case I think they're going about this the wrong way.
>I think for most cases the overhead of the crypto is not going to
>have an impact on the results because there is just way more
>jitter on the network. For the cases this matters both sides
>should take an additional timestamp when the packet was really sent,
>and have a follow up packet that contains the correct time. 

This would be a very clean solution, but my impression was always that NTP did not offer follow-up type messages (as a reminder: for NTS, we try to not require modifications to the specification of the underlying time sync protocol). Am I wrong about his?

> For
>the cases where this matters, they should already be doing this.
>
>
>Kurt
>
>_______________________________________________
>ntpwg mailing list
>[email protected]
>http://lists.ntp.org/listinfo/ntpwg
>
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc

Reply via email to