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

[Miroslav Lichvar <[e-mail]>]

On Wed, Mar 25, 2020 at 03:10:24PM +0100, Ragnar Sundblad wrote:
> 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.

I don't think they are so different. There will be a slow stream of
NTS-KE requests as clients are (re)started (not caching the
key/cookies) and clients running out of cookies when too many requests
are dropped (as is currently happening in some networks).

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

That doesn't solve the problem that clients using a short retry
interval are starving other NTS-KE clients.

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

Unless the minimum timeout is specified for clients, allowing a huge
number of open connections on the server might not prevent the clients
from making frequent NTS-KE requests.

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

That's still about 800x more expensive than an NTS-NTP client polling
at 512 second interval.

-- 
Miroslav Lichvar