At 7:05 AM -0700 2005-09-11, Nelson Minar wrote:
The pool has already made a huge contribution in that there is a
single well known place for good time on the Internet. Anything else
is gravy.
Agreed.
If you're willing to play DNS tricks, it may not be so hard to make
pool.ntp.org resolve cleverly to a host appropriate to the requesting
client. Companies like Akamai have been using DNS to send you to a
"nearby" server for years. The cost is that you need more serious DNS
serving infrastructure, since you lose a lot of caching.
This is geographic (or global) server load balancing, or GSLB.
I'm a little out of my depth here. Brad, you're a DNS expert aren't
you?
I've done technical reviews of books on this subject, I've done
consulting in this area (including consulting on behalf of vendors),
I've done invited talks on this subject, I've done seminars on this
subject, and I'm now writing a book on it, yes.
You already shot down my idea of using DNS to protect against
abusive clients; how does this idea sound?
There are many ways to do GSLB, some of them which include DNS.
I have been violently opposed to using DNS for GSLB ever since the
idea was created, and nothing has happened in the last few years to
change my mind.
Within the purview of NTP, there is a much simpler way to do this
-- use "manycast" instead. The client sends out a multicast query
with a packet TTL of zero, to see if there are any servers on the
local segment which are configured to listen to that address and
provide NTP service. If none, then it tries again with a TTL of 1.
And it continues incrementing the TTL and retransmitting until such
time as it finds enough servers to meet its configuration
requirements. Once it has found enough servers, it sets up a unicast
client/server relationship with them, and from that point it looks
just like any other unicast client/server relationship.
This is Dr. Mills' concept of how the pool should be used.
Overall, I agree with him.
The problem is that doing multicast requires support at each and
every router between the two points in question, and that support is
not typically turned on by default within most router configurations,
and most network providers don't bother to turn it on outside of
those defaults.
Moreover, when it comes to building large-scale environments (I
was the Sr. Internet E-mail Systems Administrator for AOL for two
years, so I know about scaling), it's been my experience that keeping
the system as simple as possible is the best thing you can do.
A simple round-robin scheme is likely to get you as good
performance as anything else you could implement, because there are
always going to be a whole host of factors out of your control, and
if you try to micro-manage the problem too much then you end up
creating more problems than you could possibly resolve.
In the context of the DNS servers for pool.ntp.org, what this
means is that they should not make any attempt whatsoever to do GSLB.
Instead, they should do a much simpler form of load-balancing, where
they hand out a selection of IP addresses from the pool, and rotate
which IP addresses they hand out on a frequent basis.
With the number of servers that we have in the pool today, we
can't do this with standard BIND. We'll have to use a different
program.
I don't know the program that Ask has been using in his other
projects, but it may well turn out to be acceptable for this task.
Certainly, it should be tested first, because it's the program he
already has experience with, and should be a relatively quick and
easy for him to implement, if it turns out to be suitable.
The ideal situation would be if we could hand out SRV records, so
that we could associate both a cost and a weight with each record,
and have load distributed within each cost category as a ratio of the
respective weights within that category.
Unfortunately, no client understands SRV records, so this doesn't
help us. But, we should take this to the NTP IETF Working Group, and
push them to make SRV records a part of the upcoming standard, and
then go ahead and put that into the Reference Implementation.
IMO, that's the real long-term solution, outside of techniques
like "manycast".
Then again just telling folks to use "countrycode.pool.ntp.org" for
themselves also seems sufficient.
Except when that country-code doesn't have any servers in it
anymore, or when it doesn't have enough servers in it to be useful.
Even if the OS doesn't know what
country it's in, can't you figure that out pretty easily from IP
address via one of these services?
http://www.google.com/search?q=ip+address+geocoding
No, that problem is actually a lot harder than you think it is.
This might get you 80% of the way there, but I don't think that even
an 80% solution is adequate here.
If so, then any installer can quickly configure a better DNS name than
"pool.ntp.org" without user intervention.
Again, assuming that country-code has an adequate number of
servers, which is not a valid assumption. Hell, there are even
entire regions that don't have enough servers to be used like this.
--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
