[ntp:questions] [pool.ntp.org] 87 servers so far /web server configuration / some other small things
Brad Knowles
brad.knowles at skynet.be
Tue Sep 23 17:04:35 UTC 2003
At 4:17 PM +0000 2003/09/23, David L. Mills wrote:
> There already is a mechanism in ntpd to semi-automatically select which
> stratum to favor if multiple strata are found. It is used with the
> manycast scheme, where a client broadcast lights up a herd of potential
> servers and the client needs to do some intelligent selection. Left
> without any scheme of course, the client would latch on the three
> lowest-stratum that survive the mitigation algorithms.
The problem with manycast is that it is based on multicast and
requires support at the routers, and almost certainly will not work
outside of the LAN/WAN environment of a single entity. It's useful
for large sites that may have tens of thousands, hundreds of
thousands, or multiple millions of client systems, but it's not going
to help us solve problems such as are faced today by UWisc, or other
overloaded time servers around the 'net.
At least, reading
<http://www.eecis.udel.edu/~mills/autocfg.html>, it appears that
manycast requires support for multicast, the way I read this
paragraph:
NTP Multicast/Manycast Support
NTP broadcast mode does not extend beyond the local subnet.
Where service is intended beyond the ocal subnet, IP
multicasting can be used if supported by the network
infrastructure. Various means have been developed using
these methods to discover services and resolve addresses,
for example. manycasting is an automatic dynamic discovery
and configuration paradigm. It is distinct from anycasting,
where a single service provider is selected from a number
that may respond to a multicast invitation. Manycasting is
designed for highly robust services where multiply redundant
respondents are continuously evaluated and quasi-optimal
subsets mitigated using engineered algorithms. In general,
NTP requires a plurality of servers in order for the
mitigation algorithms, which are based on Byzantine
agreement methods, to reliably cast out intruders and
provide the best timekeeping performance.
Unfortunately, it's hard enough to get sites to do regular IPv4
correctly. Most don't do bogon filtering, and the ones that do
almost always seem to get it wrong. Most don't do ingress filtering
at all, and again, the ones that do seem to largely get it wrong. I
can't imagine asking most sites to try to get multicast routing set
up correctly.
> In the pool scheme the analog of expanding ring search could be based on
> domain name. Ring zero is the set of servers in the same state, ring one
> in the same country, and so on. I kinda like this approach or something
> likee it, since support for the manycast thing is already in ntpd and it
> might not be too hard to completely automate it in the pool scheme, as
> well as the manycast scheme, or even both at the same time.
We need to first get ntpd to be more intelligent about handling
multiple IP addresses per FQDN. Once we have that, we can worry
about what to do with all those extra IP addresses that might be
available.
In particular, we would need to make sure that each pool served
by *.pool.ntp.org is of sufficient size to be useful -- having a
single server in a country-code or region pool is unhelpful and
misleading at best, and at worst is downright harmful.
--
Brad Knowles, <brad.knowles at skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
More information about the questions
mailing list