[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