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

[Ragnar Sundblad <[e-mail]>]

> On 27 Mar 2020, at 07:58, Ulrich Windl <[e-mail]> wrote:
> 
>>>> 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 don’t follow you - in my head, the nth retry is the nth retry, you
can not arbitrarily not count some retries. :-)

>>> 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.

I must have misread your first comment in some strange way, sorry!

I totally agree with you, and this is my point too regarding some issues
in these discussions.

>> 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)

So do we. That is why we also added:
"The exact workings of this will be
dependent on the application and operational experience gathered over
time.  Until such experience is available, this memo provides the
following suggestion."

This should also be read to imply that it will almost certainly not be
good values for a very low power application, very low bandwidth or very
slow networks, etc etc. It just should, we hope, work reasonably well,
for now, for the Internet, within a typical traditional LAN in a
home, datacenter or a campus/enterprise.
We had more expclicit text about this at first, but we removed the
specifics and generalised it, to keep it general and short.

>> 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 ;-)

Absolutely!
And, there is almost always something to learn from every opinion (it
may not have to do with the subject at hand, but something).


Best,

Ragnar