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

[Ragnar Sundblad <[e-mail]>]

> On 26 Mar 2020, at 10:56, Miroslav Lichvar <[e-mail]> wrote:
> 
> On Wed, Mar 25, 2020 at 04:42:10PM +0100, Ragnar Sundblad wrote:
>>> On 25 Mar 2020, at 15:59, Miroslav Lichvar <[e-mail]> wrote:
>>> 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).
>> 
>> Ok, both are network traffic, we can agree on that.
>> 
>> And one could starve the other, and if they share resources, that
>> should be taken care of, I hope we can agree on that too.
> 
> Yes, I agree.
> 
> But it seems we don't agree on how long actually will be the NTS
> sessions. You seem to be saying that a short initial interval in the
> exponential backoff is ok (in the name of simplicity), because the NTS
> sessions will be so long that the average rate will be insignificant
> over those long periods. Is that correct?

Hmm, I don’t think so. Also, do you mean one KE negotiation is one session,
or from one KE negotiation to the next one, if the clients reboots runs out
of cookies is one session?

I did mean, that the initial 10 seconds will only be 10 seconds if the server
is up but will not accept the TCP connection, if for example the listener
has not started, or is so overloaded that the TCP connection queue is full
(and this will be very cheap for the server, handled by TCP).
If the server is not up or not reachable, TCP will retry for a while before
giving up. (This will of course not cost the server anything.)
If the server accepts the TCP connection but is overloaded and slow to
respond, the client will just wait for the request to be handled (and could,
likely should, timeout after a while). There is no extra cost for the
server for this, really.

> I don't think that will be the case. I think it will be similar to the
> current NTP traffic. Some people just don't like running "unnecessary"
> daemons and run an NTP client from cron in an ntpdate mode.

Maybe, I don’t know. I don’t think the timers will have a lot of impact
on this though, such a client should timeout pretty quickly anyway, right?
And more importantly - the timers shouldn’t come into play, since that
means that something is overloaded or broken.

> Computers
> are shut down or suspended frequently.

If they are suspended, there is no need to renegotiate.
(I reboot my machine only when there is a new kernel or other major
thing that requires it, it seems to me almost everyone else do too, my
colleagues, my parents, my kids, everybody I can think of.)
But the timer constants have no impact on this, normally things should
work and not be overloaded, and the timers should not come into play.

> Clients are switching between
> different servers of a pool.

Only when the ntp client is restarted, right (at least with the clients
of today).
But even if a client would change NTP server very often and load the
KE servers, that could not be fixed by changing those constant either.

> I think it will take only a small portion of NTS clients to be
> consistently failing in NTS-KE or NTS-NTP after the TLS handshake
> (e.g. due to a network issue, bug, or incompatibility) and overwhelm
> the server with their short retry intervals.

They should not fail with a working server, why would they?
And if they do, they will very quickly get to long retry intervals,
and there is likely something broken with the server anyway.

Ragnar