[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] NTP and various proposals.



On Mon, Feb 25, 2008 at 7:06 PM, Randall Atkinson
<rja@extremenetworks.com> wrote:
>  I must be missing something in this recent exchange...
>
>  How is it different for NTP in some future proposal than
>  for current NTP in today's Internet along a path that has
>  very high degrees of path variability over time ?

Ran,

NTP works by measuring the behavior of the network between the client
and the server in order to estimate the amount of time it took for the
timestamped packet to reach the client so that the client can set the
correct time. NTP is killed by jitter: whatever the round trip times
are, they have to be fairly consistent from attempt to attempt. Some
paths on the network today will have higher jitter than others. This
is one of the reasons you configure a number of servers for the
client: so that if the path to a server has a high jitter then the NTP
client can exclude it and synchronize with the rest.

Every caching map-encap scheme where every ITR does not have a full
map will experience a delay (some small, some large) during the cache
pull. The NTP client will experience this as jitter: one packet has a
round trip of 400 ms and the next has a round trip of 30 ms. The
client will assume that means it can't accurately estimate the time it
takes to get a packet back to it from the server so it will mark that
server as ineligible for synchronization until the network path clears
up.

If the NTP client regularly communicated with the server, this
wouldn't be a problem. It would see high jitter on the initial attempt
which would settle right down. But NTP is a well behaved protocol.
When the server is responding well and it's in sync, NTP backs off to
where it sends only a single query every thousand seconds or so.
That's more than enough time for the ITR to expire and remove the
cached ETR entry so that on the next attempt NTP sees: jitter.

NTP is really a great litmus test. Every map-encap proposal should
have an explanation for how NTP works during and following deployment.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg