On Mar 8, 2009, at 21:24, Danny Mayer wrote:
i'm not sure we're in the same discussion. pool.ntp.org is using
short
ttl and silent truncation and round robin. there's no geo-ip
stability
that could be hurt by client-side reordering or rerandomizing. and
the
nameserver examples you gave are all subject to rdns RTT sorting.
the
"large RRset" approach works just fine, and is not related to Rule 9.
pool.ntp.org divides itself up into subdomains (okay they are really
hostnames) for each country-code so that you get addresses in that
country code. NTP in the future will take advantage of the fact that
it
gets back multiple addresses and will use more than just one of them
to
find NTP servers. The order does not really matter and it's better
that
there be no particular order so that we do not overload any one
server.
Hi everyone,
Funny the NTP Pool was brought up as an example. I'm looking after
pool.ntp.org and I actually subscribed earlier in the week to comment
on the round robin issue. :-)
It's a little more complicated than what Paul described above
(although it worked like that until ~2005 when I took over maintaining
the system).
When you query pool.ntp.org (or 1.pool.ntp.org etc), the DNS server
does the "IP to geo-location" thing to automatically select the "sub-
zone". You can also explicitly ask for the sub-zone with
0.us.pool.ntp.org, 0.north-america.pool.ntp.org, etc.
Paul is right that there's no problems with geo-stability because the
DNS server will generally just give you servers from one area anyway;
but we can get hurt by dumb re-ordering.
For distributing the load[1] we depend on clients making mostly random
picks when receiving multiple A records.
Within each "zone" we have anywhere from a dozen to 1000+
servers[2]. The DNS server will return a list of A records weighted
by the bandwidth the server administrator have told us they have.
This is absolutely crucial. Before I implemented the current system,
we just used a frequently updated zone with rotating A records and
once or twice a day server operators with a small pipe (say a T1) or a
small scale "router" would get overloaded enough that they'd leave the
pool.
It's critical to the longevity and the geographic diversity of the
pool that "small operators" are able to contribute; even if they
handle much less traffic than others.
If "RFC 3484 section 6 rule 9" really is implemented with "matching"
prefixes all the way up to /2, I'd worry that could mess up the
weighting we do and cause operators on "unlucky" IP addresses to have
to stop offering their service.
Since the DNS server does most of the weighting by giving just a few
records from a usually much larger set, I could just return fewer A
records to force "my choice". But returning ~5 A records is valuable
- some NTP servers knows how to use multiple A records from one lookup
(ntpd in the future being one of them, as Danny pointed out).
Having the client be "smart" would be absolutely unhelpful. Someone
was arguing that the client might have useful network knowledge to
apply. I don't know of any actual implementations of that whereas
there are lots of deployed implementations with the DNS server being
smart and/or deliberate about the records returned.
- ask
[1] The NTP Pool is used a lot. You'd have an unlikely network to not
have some local users. It's the default in for example most Linux
distributions and many consumer devices. Practically none of the
manufacturers contribute anything back; but the whole point of the NTP
Pool is to preserve NTP as a useful public resource, so better us than
some poor overloaded NIST server!
I don't know how many clients we have; but the name servers do about
20m requests a day; and that's basically only counting "dumb" ntp
clients because the long running daemons generally just do one set of
lookups on startup. It also, obviously, doesn't count the effects of
local caches. In any case: It's a lot of users.
[2] There are ~1743 active server in the pool right now distributed
around the world: http://www.pool.ntp.org/zone - about 1000 in Europe
and just under 600 in North America, http://www.pool.ntp.org/zone/
europe and http://www.pool.ntp.org/zone/north-america
--
http://develooper.com/ - http://askask.com/
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf