Re: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-27.txt

[Ragnar Sundblad <[e-mail]>]

> On 27 Mar 2020, at 08:47, Harlan Stenn <[e-mail]> wrote:
> 
> 
> 
> On 3/27/2020 12:15 AM, Ragnar Sundblad wrote:
>> 
>> 
>>> On 26 Mar 2020, at 21:10, Hal Murray <[e-mail]> wrote:
>>> 
>>> 
>>>>>>> No, clients may switch between servers when they become unreachable
>>>>>>> (e.g. due to rate limiting). I see this often with my mini-pool of NTS
>>>>>>> servers.
>>> 
>>>>>> Oh really, I didn’t know. So chrony does that? (Nice!)
>>>>> I think most NTP and SNTP clients do that.
>>> 
>>>> Right, SNTP most likely. But NTP? Oh well. 
>>> 
>>> In pool mode, yes.
>>> 
>>> With the current pool, there is no way to ask "Is this site still in the pool?"
>>> (There isn't a clean way to turn off traffic when you remove a site from the 
>>> pool.)
>>> 
>>> It makes sense when a site stops responding to go through the DNS step again 
>>> and try a new server.
>>> 
>>> It would also make sense for sites that are up 24/7 to do something like once 
>>> a day, scan the list of pool servers currently in use and kick out the worst 
>>> one and try a new one.  The idea is to gradually pick servers that are better, 
>>> probably nearer, but distance measured in network performance rather than 
>>> kilometers.
>> 
>> Sounds like a very good idea!
>> 
>> (I suppose you should take into consideration especially jitter, but also
>> loss, and the larger the round trip, the higher the risk for large
>> asymmetries = phase error and phase variations when routing change,
>> and the current measured phase error should probably also take into
>> account, and there are probably other things. Interesting problem!)
> 
> This has always been part of the 'pool' directive in the Reference
> Implementation.

Very nice!

(Is it just me, or is there room for improvements of the documentation of
the pool directive in several of the implementations?)

Ragnar