[ntp:hackers] NTP protocol

todd glassey tglassey at earthlink.net
Sun Dec 18 21:21:25 UTC 2011


On 12/18/2011 11:38 AM, Danny Mayer wrote:
> On 12/9/2011 10:38 AM, Brian Utterback wrote:
>> On 12/09/11 08:06, Danny Mayer wrote:
>>> On 12/8/2011 9:49 AM, Duker, Steven wrote:
>>>>>   Hi
>>>>>   >   I was interested in learning if there is a version of NTP that
>>>> supports TCP verses UDP broadcasting.
>>>>>
>>> No. It's a UDP-only protocol. It would make no sense to do NTP over TCP.
>>> It will never support TCP.
>>>
>> Since you ask this question, I presume that you do not understand why
>> TCP wouldn't work and that Danny's completely accurate reply may be a
>> bit too terse to be helpful to you.
>>
>> The key issue with NTP is that the packets used must be delayed by as
>> short a time as possible. Every time a packet is delayed in transit, an
>> error is introduced in the resulting offset calculation. The size of the
>> error is directly proportional to the total delay. Since it takes two
>> packets to make the calculation (a request and a reply) the error is
>> accumulated in both directions. The total roundtrip time of the two
>> packets gives a absolute cap on the offset calculation error.
>>
>> Now in the real world packets sometimes get dropped. NTP does not
>> re-transmit dropped packets, it is designed to use the data it does get
>> and can just skip the calculation when a packets gets dropped.
>>
>> Given the above, consider what happens with TCP. If the packet gets
>> delivered, great, the NTP calculation will end up being the same as it
>> would be with UDP. But with TCP, packets are not always sent right away
>> due to congestion control, and when a packet gets dropped, TCP
>> retransmits the packet.
Yes. So there is a retransmit error that would introduce here but that 
can be dealt with in the protocol too.
>> So, when the packet is finally delivered to NTP,
>> there is no way to know if the packet was delayed or retransmitted.
True because of the way the transport is set up but that also could be 
addressed.
>>   So
>> with TCP, a packet that got retransmitted could show a roundtrip time in
>> the 10s of seconds, which is worthless to NTP. Worse, if the server and
>> client are close together networkwise, the roundtrip time might only
>> have been increased by a few 10s of milliseconds and would be
>> indistinguishable from a normal exchange to a server further away.
True but the issue here is that you cannot build a one-size fits all 
solution.
>
> And the real killer is that although the roundtrip time places a cap on
> the error, in practice the actual error is usually much smaller. The
> real error introduced is dependent not on the total delay, but the on
> the asymmetric delays.
Again this brings into play issues only experienced on the Open Internet 
and not over closed topology networks. But  asymmetric back-haul 
agreements introduce this same effect into UDP transmissions across 
large topologies as well so the same effect happens every time the 
Internet is used. Further NTP doesnt map the route in takes out vs the 
receive routing so the same issue is true at the application context 
here as well.
>> That is, if a request packet is delayed 10ms by a
>> router on the outbound journey and then the router delays the reply by
>> the same 10ms on the reply, then the error cap would be increased, but
>> the actual error introduced would be zero. But a packet retransmission
>> is in one direction only, and the whole delay for retransmission
>> directly contributes to the actual error.
>>
>> For these reasons, TCP is completely unsuitable for use by the NTP
>> protocol for timing calculations.
SO let me push back here - TPC based connections are good if the pipe 
and control practice are capable of being put in place and you can also 
enforce packet shaping as well. The problem is this is well beyond the 
capabilities of the average person and most Systems Admins as well.
>> There might be a place for it in terms
>> of control functions that are not time critical, but the current
>> reference implementation does not allow for this, nor do the governing
>> RFC's.
>>
> The other thing that Brian missed in his explanation is the with TCP the
> server needs to hold open a connection to the client until it is done
> and the limited number for file descriptors means for heavily used
> servers you are limited by the number of file descriptors you can use.
Which may be a policy control issue.
> In addition you have setup/teardown requirements for the connection and
> you are spending a lot of CPU doing this.
This is based on traditional architectures and not new ones per se.
> NTP is designed for UDP and not TCP.
>
> Danny
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> http://lists.ntp.org/listinfo/hackers
>


-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.



More information about the hackers mailing list