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

> On 27 Mar 2020, at 08:33, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
> 
>>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 26.03.2020 um 15:01 in
> Nachricht
> <5022_1585231330_5E7CB5E2_5022_507_1_20200326140143.GD9039@localhost>:
>> On Thu, Mar 26, 2020 at 02:01:16PM +0100, Ragnar Sundblad wrote:
>>> 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.
>> 
>> Rate limiting of NTP packets in some networks is a major issue, which
> 
> Maybe the next NTP specification should talk about the QoS bits.

I heard this story about a larger networking equipment company that had
some internal bandwidth problems (quite surprisingly, but I suppose
there was a good reason), so they started to use QoS internally, and
priorities e.g. VoIP traffic to not have them break up.
Since most of the employees were networking savvy, of course they
started to run all their traffic from their own machines with highest
possible priority. When they all did that, they were back where they
had started.

I think it is hard to make QoS work in anything but extremely
controlled environments.

>> was discussed on this list. I sometimes see over 90% packet loss. The
>> client would need to reuse cookies to operate reasonably well in such
>> conditions. I agree the 8 polling intervals from NTP helps here
>> (assuming the interval is not reset to the minimum after NTS-KE and
>> it's not using a burst).
>> 
>>>> 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 most NTP and SNTP clients do that.
> 
> Specifically Manycast and Pool configurations work like that.

You are right, of course!

>>>> 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.
>> 
>> You are right. Good point. Maybe a bug or incompatibility between
>> different implementations would be a better example.
>> 
>> -- 
>> Miroslav Lichvar
>> 
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ntp 
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

Best,

Ragnar