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

Hi Miroslav,

NTP traffic and KE traffic are very different; KE traffic is supposed to occur
very seldom, NTP traffic is a constant (very slow) stream, and I don’t think
they can be compared in any really useful way.

If they share resources, like running on a single server, one could starve the
other. It may be a good idea to prioritise NTP responses, at least to a
certain extent, in a typical use case. This has to be studied, I think.

Note that if there are many new TCP connections pending and server doesn’t
even accept new connections, the cost for the server is considerably
less than even for replying to NTP.
If the server listens but is slow to respond, the client will just hang
there for a while until it gets a response (or timeouts), with a very
small cost.

Also note that it takes 9 tries to get to to a retry interval of more than
1024, and that the average request interval up to that point is about
2 minutes.

We do not want to complicate this more than absolutely necessary.

Best regards,

Ragnar

> On 25 Mar 2020, at 12:58, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> 
> 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.
> 
> -- 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp