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

>>> Miroslav Lichvar <mlichvar@redhat.com> 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‑drafts@ietf.org 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.

I think it's more important that the interval should increase than specifying
the actual numbers (initial value, maximum value).

> 
> ‑‑ 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 