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

[Ragnar Sundblad <[e-mail]>]

> On 26 Mar 2020, at 12:37, Miroslav Lichvar <[e-mail]> wrote:
> 
> On Thu, Mar 26, 2020 at 11:49:57AM +0100, Ragnar Sundblad wrote:
>>> On 26 Mar 2020, at 10:56, Miroslav Lichvar <[e-mail]> wrote:
>>> 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?
> 
> By session I mean how long the client is using or trying to use the
> server, including all NTS-KE and NTS-NTP requests.

Ok! Yes, then I think you could say so.

>> 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.
> 
> Yes, but I'm concerned with the cases where something breaks after the
> connection is made and when much more resources are wasted per
> request.

Oh, so you think there is a risk that both the KE negotiation works
and at least one NTP requests works, and soon thereafter the
connection breaks, frequently?
I am not sure why that would happen very often, but if it did, there
Should at least be 8 NTP requests (until the client has exhausted its
cookies) until it contacts the KE server again.

>>> Computers
>>> are shut down or suspended frequently.
>> 
>> If they are suspended, there is no need to renegotiate.
> 
> Usually, but the system may need to restart the NTP client due to a
> different DHCP configuration for example.

(If it is implemented like that, persistent cookies could be a nice
addition.)
But this is also something that isn’t affected by the retry timer
constants - it should work on the first attempt anyways.

>>> Clients are switching between
>>> different servers of a pool.
>> 
>> Only when the ntp client is restarted, right (at least with the clients
>> of today).
> 
> No, clients may switch between servers when they become unreachable
> (e.g. due to rate limiting). I see this often with my mini-pool of NTS
> servers.

Oh really, I didn’t know. So chrony does that? (Nice!)

>>> 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.
> 
> Well, as I said above, there are many reasons why NTS-KE or NTS-NTP
> may be consistently failing. For example, an ISP may have a firewall
> that blocks large NTP packets. NTS-KE will work as expected, but
> no NTS-NTP reply will be ever received, so the clients will be
> constantly restarting NTS-KE. If the clients were restarted once per
> day and used the 1024*2^(n - 1) retry interval I suggested, the number
> of NTS-KE requests would drop to 30%.

Ok - in this case too, there should be 8 NTP requests before it contacts
the KE server again, and it will increase the retry interval each time
since it has not completed a full cycle of getting cookies and succeeded
in using them.

Ragnar