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

[Ulrich Windl <[e-mail]>]

>>> Ragnar Sundblad <[e-mail]> schrieb am 25.03.2020 um 15:58 in
Nachricht
<[e-mail]>:

> 
>> On 25 Mar 2020, at 14:08, Ulrich Windl <[e-mail]>

> wrote:
>> 
>>>>> Miroslav Lichvar <[e-mail]> schrieb am 25.03.2020 um 12:58
in
>> Nachricht
>> <7711_1585137556_5E7B4794_7711_872_1_20200325115834.GC25803@localhost>:
>>> On Tue, Mar 24, 2020 at 11:02:28AM ‑0700, internet‑[e-mail] wrote:
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft‑ietf‑ntp‑using‑nts‑for‑ntp‑27 
>>> 
>>> One of the changes in the latest version is a new section on
>>> recommended NTS‑KE retry intervals. There was some discussion in the
>>> github issue #153 and there was a suggestion to continue here.
>>> 
>>> Does anyone else think that the minimum retry interval of 10 seconds
>>> is way too short?
>>> 
>>> I think it should be at least 1024 seconds (corresponding to the
>>> default NTP maxpoll), with an exception for retrying a TCP connection
>>> when the server doesn't accept the connection, or it's closed before
>>> the TLS handshake to implement a rate limiting. Is there anything else
>>> that would be likely to change on the server for the NTS‑KE to succeed
>>> just after 10 seconds?
>>> 
>>> In my tests NTS‑KE seems to be about 200x more expensive than an
>>> NTS‑NTP (a single core handling about 500 NTS‑KE requests per second
>>> or 100000 NTS‑NTP requests per second). That's with the AES‑NI
>>> support.
>>> 
>>> A widely used polling interval of NTP clients is between 64 and 1024
>>> seconds. That means a single NTS client retrying NTS‑KE after only 10
>>> seconds wasted the same amount of resources as about 10000 clients
>>> using only NTS‑NTP. That's crazy.
>>> 
>>> Yes, the server can limit the number of threads available to NTS‑KE or
>>> limit the connection rate, but that will have a disproportionate
>>> impact on clients using more reasonable retry intervals.
>>> 
>>> I suggest to modify the second paragraph of the section to the
>>> following:
>>> 
>>>  Clients SHOULD use an exponential backoff with a base of 2. The
>>>  initial retry interval SHOULD be at least 16 seconds if the previous
>>>  NTS‑KE connection failed, or the server closed it before the TLS
>>>  handshake, and 1024 seconds in other cases. The maximum interval
>>>  SHOULD be at least 524288 seconds (~6 days). The minimum interval in
>>>  seconds, t, for the nth retry can be calculated as
>>> 
>>> 		t = min(R * 2^(n‑1), 2^19)
>>> 		where R is 16 or 1024 depending on the previous error
>>> 
>>> I suggest powers of 2 to make it compatibille with NTP polling
>>> intervals and avoid floating point operations.
>> 
>> The only variable that is implicitly specified as 1 is how many failures
>> should happen before the retry interval is extended according to the
>> exponential backoff strategy. I can imaging a number like 2 or 3 being used

> as
>> well.
> 
> Not really, since it says "nth retry”, and n is in the equation.

I was referring to the case "try < n", i.e. n is not incremented every try.

> 
>> I think it's more important that the interval should increase than 
> specifying
>> the actual numbers (initial value, maximum value).
> 
> Do you have something to support this?

It's like O(1) vs. O(n): O(1) may be slower for some cases, but eventually it
will be faster than O(n). Simple as that.

> 
> We believe that this should work reasonable well for a typical traditional
> ethernet LAN with few computers up to a datacenter booting or for a server
> on the internet.

Technology changes: I can remember when a "fast" transfer rate via FTP was
2kB/s and packet response times were 100ms to 1.5s, the on a 10Mb LAN the
response times were like 10ms, while I see < 1ms today. The number of servers
increased dramatically since then.

Therefor I feel all concrete timeout or delay numbers in protocol
specifications should be avoided if possible. (When Microsoft implemented DHCP
they did not care about the timing specifications found in the RFC, making
Microsoft DHCP "faster" than the standard)

> 
> Do you have any comments to my earlier reply (that I sent after this
reply)?
> 
> (And, whatever we say, someone will be unhappy.)

Yes that's democracy; still we may express our opinions occasionally ;-)

Regards,
Ulrich Windl