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

[Ragnar Sundblad <[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 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?

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.

Do you have any comments to my earlier reply (that I sent after this reply)?

(And, whatever we say, someone will be unhappy.)

Ragnar