[ntp:questions] [pool.ntp.org] 87 servers so far /webserver configuration / some other small things

David L. Mills mills at udel.edu
Tue Sep 23 20:06:36 UTC 2003


Brad,

I didn't explain myself very well. The intent is that both manycast and
pool use similar algorithms, but each is separate and implements the
data gathering scheme in different ways. I fully understand multicast is
not ubiquitous, not even outside our department here, and the only wide
area experiment where it definitely was ubiquitous was the now retired
CAIRN network once funded by DARPA. Once upon a time long ago we had a
private T1 tail circuit to CAIRN and did all kinds of interesting
multicast stuff with real time video, audio and whiteboard before
anybody even heard of it. Interestingly, some of my students work for
Comcast and they tell me multicast is alive and well within their
network, just not available for customer use.

So, the intent is that the pool concept and manycasdt concept should
learn from each other.

Dave

Brad Knowles wrote:
> 
> 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