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

From: [email-masked]
Date: Tue, 24 Mar 2020 11:02:28 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

        Title           : Network Time Security for the Network Time Protocol
        Authors         : Daniel Fox Franke
                          Dieter Sibold
                          Kristof Teichel
                          Marcus Dansarie
                          Ragnar Sundblad
	Filename        : draft-ietf-ntp-using-nts-for-ntp-27.txt
	Pages           : 44
	Date            : 2020-03-24

Abstract:
   This memo specifies Network Time Security (NTS), a mechanism for
   using Transport Layer Security (TLS) and Authenticated Encryption
   with Associated Data (AEAD) to provide cryptographic security for the
   client-server mode of the Network Time Protocol (NTP).

   NTS is structured as a suite of two loosely coupled sub-protocols.
   The first (NTS-KE) handles initial authentication and key
   establishment over TLS.  The second handles encryption and
   authentication during NTP time synchronization via extension fields
   in the NTP packets, and holds all required state only on the client
   via opaque cookies.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-27
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp-27

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-using-nts-for-ntp-27

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 25 Mar 2020 12:58:34 +0100

> 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

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 25 Mar 2020 14:08:39 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 25.03.2020 um 12:58 in
Nachricht
<7711_1585137556_5E7B4794_7711_872_1_20200325115834.GC25803@localhost>:
> On Tue, Mar 24, 2020 at 11:02:28AM ‑0700, internet‑[email-masked] wrote:
>> https://www.ietf.org/rfcdiff?url2=draft‑ietf‑ntp‑using‑nts‑for‑ntp‑27 
> 
> recommended NTS‑KE retry intervals. There was some discussion in the
> 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.
> 
> seconds. That means a single NTS client retrying NTS‑KE after only 10
> using only NTS‑NTP. That's crazy.
> 
> Yes, the server can limit the number of threads available to NTS‑KE or
>   NTS‑KE connection failed, or the server closed it before the TLS
> 		t = min(R * 2^(n‑1), 2^19)

The only variable that is implicitly specified as 1 is how many failures
should happen before the retry interval is extended according to the
exponential backoff strategy. I can imaging a number like 2 or 3 being used as
well.

I think it's more important that the interval should increase than specifying
the actual numbers (initial value, maximum value).

> 
> ‑‑ 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Ragnar Sundblad <[email-masked]>
Date: Wed, 25 Mar 2020 15:10:24 +0100

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 <[email-masked]> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Mar 2020 14:28:35 +0000

I agree with Miroslav's concerns and solution.

---

From: Ragnar Sundblad <[email-masked]>
Date: Wed, 25 Mar 2020 15:58:55 +0100

> On 25 Mar 2020, at 14:08, Ulrich Windl <[email-masked]> wrote:
> 

Not really, since it says "nth retry”, and n is in the equation.

> the actual numbers (initial value, maximum value).

Do you have something to support this?

We believe that this should work reasonable well for a typical traditional
ethernet LAN with few computers up to a datacenter booting or for a server
on the internet.

Do you have any comments to my earlier reply (that I sent after this reply)?

(And, whatever we say, someone will be unhappy.)

Ragnar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 25 Mar 2020 15:59:56 +0100

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

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

> there for a while until it gets a response (or timeouts), with a very

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.

> 1024, and that the average request interval up to that point is about

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

-- 
Miroslav Lichvar

---

From: Ragnar Sundblad <[email-masked]>
Date: Wed, 25 Mar 2020 16:42:10 +0100

> On 25 Mar 2020, at 15:59, Miroslav Lichvar <[email-masked]> wrote:
> 

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.

> interval are starving other NTS-KE clients.

They will not starve the other KE clients, they will just be served
in the order their requests got handled. Tweaking the constants will
not change this.

> from making frequent NTS-KE requests.

The minimum timeout can be considered to be zero, of you want.
Then it would be only the retry interval that counts.
After a very few retries, when the retry interval has increased
enough, the timeout is likely uninteresting anyway.

(In reality, the timeout will of course be larger than zero.)

> That's still about 800x more expensive than an NTS-NTP client polling

If you say so, I trust you, and I think this sounds entirely reasonable.
I am not sure what that has to do with anything though.
It can be prioritised to handle 800, or 80000 times, more NTP requests
than KE requests, if you like.

(An NTP client that haven’t had contact with the server for a while
will in many cases have a poll interval of 16 or 64 s, depending on
implementation and settings, so I don’t know why 512 would be
relevant here, but this is just another example of how they don’t
really compare.)

Again, whatever we choose, someone will be unhappy.

/ragge

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 26 Mar 2020 10:56:02 +0100

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

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. Computers
are shut down or suspended frequently. Clients are switching between
different servers of a pool.

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.

-- 
Miroslav Lichvar

---

From: Ragnar Sundblad <[email-masked]>
Date: Thu, 26 Mar 2020 11:49:57 +0100

> On 26 Mar 2020, at 10:56, Miroslav Lichvar <[email-masked]> wrote:
> 

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.

> 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

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.

> 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

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 26 Mar 2020 12:37:45 +0100

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

> likely should, timeout after a while). There is no extra cost for the

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.

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

> Only when the ntp client is restarted, right (at least with the clients

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.

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

-- 
Miroslav Lichvar

---

From: Ragnar Sundblad <[email-masked]>
Date: Thu, 26 Mar 2020 14:01:16 +0100

> On 26 Mar 2020, at 12:37, Miroslav Lichvar <[email-masked]> wrote:
> 

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

> connection is made and when much more resources are wasted per

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.

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

> (e.g. due to rate limiting). I see this often with my mini-pool of NTS

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

> 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

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 26 Mar 2020 15:01:43 +0100

> cookies) until it contacts the KE server again.

Rate limiting of NTP packets in some networks is a major issue, which
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).

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

I think most NTP and SNTP clients do that.

> since it has not completed a full cycle of getting cookies and succeeded

You are right. Good point. Maybe a bug or incompatibility between
different implementations would be a better example.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Thu, 26 Mar 2020 07:07:28 -0700

[email-masked] said:
> 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. 

I think you are underestimating the ability of complicated systems to screw up 
in ways that are not anticipated and/or for people to write and read 
complicated specs.

Consider Miroslav's example of TCP working while UDP gets firewalled.  (My 
code would not be nice in that case, and I'm a nut-case about retrying too 
hard.  I'll have to think about how to fix that.)  When does the NTS-KE retry 
timer get reset?  How many independent retry timers do we need?  (Do we need 
another for DNS?)

I think this area is complicated enough that we shouldn't try to over engineer 
it.  What can we say that will be easy to understand and cover most of cases 
we can think of today?  Being overly conservative is OK with me.

Can we list nasty cases?  Can we push things like that to some other document 
that is easier/faster to update?

Do we want to add something like:
  This area lacks experience.  Code using NTS-KE MUST NOT be installed in 
places where it can't or won't be updated.

----------

I got mail saying
The IESG has approved the following document:
- 'Network Time Security for the Network Time Protocol'
  (draft-ietf-ntp-using-nts-for-ntp-28.txt) as Proposed Standard

Is there any point in discussing things like this?

Do we get to see a version after the editor fixes the tbds and such yet before 
it is officially published?

-- 
These are my opinions.  I hate spam.

---

From: Hal Murray <[email-masked]>
Date: Thu, 26 Mar 2020 07:19:16 -0700

[email-masked] said:
> You are right. Good point. Maybe a bug or incompatibility between different
> implementations would be a better example. 

That doesn't help much.  If some idiot sets minpoll to 4 you only get 40 
seconds between NTS-KE retries.

Bugs, firewalls, rate limiting, ...

---

From: Ragnar Sundblad <[email-masked]>
Date: Thu, 26 Mar 2020 16:20:53 +0100

> On 26 Mar 2020, at 15:01, Miroslav Lichvar <[email-masked]> wrote:
> 

Right, SNTP most likely.
But NTP? Oh well.

> different implementations would be a better example.

Yes, bugs could cause almost any behaviour, but it is a very specific
and narrow class of bugs that we would fix by changing those constants.

Ragnar

---

From: Ragnar Sundblad <[email-masked]>
Date: Thu, 26 Mar 2020 16:31:49 +0100

> On 26 Mar 2020, at 15:07, Hal Murray <[email-masked]> wrote:
> 
> 
> [email-masked] said:
> timer get reset?

"Clients MUST NOT reset the retry interval until they have performed a
successful key establishment with the NTS-KE server, followed by a
successful use of the negotiated next protocol with the keys and data
established during that transaction.”

So, as I said to Miroslaw, there will be a KE, 8 NTP requests,
increasing retry timer, repeat.

>  How many independent retry timers do we need?

One per NTS-enabled-NTP server.

>  (Do we need 

I don’t think so, but you probably know better than me!

> we can think of today?  Being overly conservative is OK with me.

Have you checked out Section 4.2 in draft v28?
<https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-28#section-4.2>

> Can we list nasty cases?

Do we know of any yet?
But there probably will be, that is one of the at least three reasons
that the draft says:
"The exact workings of this will be dependent on the application and
operational experience gathered over time.  Until such experience
is available, this memo provides the following suggestion.”

> Can we push things like that to some other document 

That would be nice!
Is there anything similar for other protocols?

> places where it can't or won't be updated.

We likely can’t change the the spec at this time, but again, this
particular issue will likely develop over time.

> it is officially published?

I suppose, I’ll check!

Ragnar

---

From: Ragnar Sundblad <[email-masked]>
Date: Thu, 26 Mar 2020 16:40:27 +0100

> On 26 Mar 2020, at 15:19, Hal Murray <[email-masked]> wrote:
> 
> 

It does help in most cases, right?

Anyone could do just about anything, we can’t protect against that.

The other cases I think we have already discussed, some more than
once.

Also an extra KE is not the end of the world.
Other have proposed DTLS protected NTP - that would be the
equivalent of one KE per NTP requests.

And again - whatever is done here; If the two server mechanisms shares
resources, such as CPU, they should have some kind of prioritisation
so that one can’t entirely starve the other, which will solve most
of these cases and also several different overload cases.
I am quite certain that there is absolute nothing we can specify that
can replace that.

Ragnar

---

From: Hal Murray <[email-masked]>
Date: Thu, 26 Mar 2020 13:10:30 -0700

> Right, SNTP most likely. But NTP? Oh well. 

In pool mode, yes.

With the current pool, there is no way to ask "Is this site still in the pool?"
(There isn't a clean way to turn off traffic when you remove a site from the 
pool.)

It makes sense when a site stops responding to go through the DNS step again 
and try a new server.

It would also make sense for sites that are up 24/7 to do something like once 
a day, scan the list of pool servers currently in use and kick out the worst 
one and try a new one.  The idea is to gradually pick servers that are better, 
probably nearer, but distance measured in network performance rather than 
kilometers.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 27 Mar 2020 07:58:53 +0100

>>> Ragnar Sundblad <[email-masked]> schrieb am 25.03.2020 um 15:58 in
Nachricht
<[email-masked]>:

> 
>> On 25 Mar 2020, at 14:08, Ulrich Windl <[email-masked]>

> wrote:
>> exponential backoff strategy. I can imaging a number like 2 or 3 being used

> as

I was referring to the case "try < n", i.e. n is not incremented every try.

> Do you have something to support this?

It's like O(1) vs. O(n): O(1) may be slower for some cases, but eventually it
will be faster than O(n). Simple as that.

> ethernet LAN with few computers up to a datacenter booting or for a server

Technology changes: I can remember when a "fast" transfer rate via FTP was
2kB/s and packet response times were 100ms to 1.5s, the on a 10Mb LAN the
response times were like 10ms, while I see < 1ms today. The number of servers
increased dramatically since then.

Therefor I feel all concrete timeout or delay numbers in protocol
specifications should be avoided if possible. (When Microsoft implemented DHCP
they did not care about the timing specifications found in the RFC, making
Microsoft DHCP "faster" than the standard)

> (And, whatever we say, someone will be unhappy.)

Yes that's democracy; still we may express our opinions occasionally ;-)

Regards,
Ulrich Windl

---

From: Ragnar Sundblad <[email-masked]>
Date: Fri, 27 Mar 2020 08:15:39 +0100

> On 26 Mar 2020, at 21:10, Hal Murray <[email-masked]> wrote:
> 
> 

Sounds like a very good idea!

(I suppose you should take into consideration especially jitter, but also
loss, and the larger the round trip, the higher the risk for large
asymmetries = phase error and phase variations when routing change,
and the current measured phase error should probably also take into
account, and there are probably other things. Interesting problem!)

Ragnar

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 27 Mar 2020 08:33:17 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 26.03.2020 um 15:01 in
Nachricht
> 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 think most NTP and SNTP clients do that.

Specifically Manycast and Pool configurations work like that.

---

From: Ragnar Sundblad <[email-masked]>
Date: Fri, 27 Mar 2020 08:46:46 +0100

> On 27 Mar 2020, at 07:58, Ulrich Windl <[email-masked]> wrote:
> 

I don’t follow you - in my head, the nth retry is the nth retry, you
can not arbitrarily not count some retries. :-)

> will be faster than O(n). Simple as that.

I must have misread your first comment in some strange way, sorry!

I totally agree with you, and this is my point too regarding some issues
in these discussions.

> Microsoft DHCP "faster" than the standard)

So do we. That is why we also added:
"The exact workings of this will be
dependent on the application and operational experience gathered over
time.  Until such experience is available, this memo provides the
following suggestion."

This should also be read to imply that it will almost certainly not be
good values for a very low power application, very low bandwidth or very
slow networks, etc etc. It just should, we hope, work reasonably well,
for now, for the Internet, within a typical traditional LAN in a
home, datacenter or a campus/enterprise.
We had more expclicit text about this at first, but we removed the
specifics and generalised it, to keep it general and short.

> Yes that's democracy; still we may express our opinions occasionally ;-)

Absolutely!
And, there is almost always something to learn from every opinion (it
may not have to do with the subject at hand, but something).

Best,

Ragnar

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 27 Mar 2020 00:47:06 -0700

> account, and there are probably other things. Interesting problem!)

This has always been part of the 'pool' directive in the Reference
Implementation.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Ragnar Sundblad <[email-masked]>
Date: Fri, 27 Mar 2020 08:53:51 +0100

> On 27 Mar 2020, at 08:33, Ulrich Windl <[email-masked]> wrote:
> 

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.

> Specifically Manycast and Pool configurations work like that.

You are right, of course!

Best,

Ragnar

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 27 Mar 2020 09:04:43 +0100

>>> Ragnar Sundblad <[email-masked]> schrieb am 27.03.2020 um 08:53 in Nachricht

> possible priority. When they all did that, they were back where they

That the issue with all priorities (like process priorities, print job priorities, etc.): You tell the system what you want, and the system tries to fulfill your request.
Probably the system only works if either it's all used by a single authority, or if priority is more expensive ;-)

On my personal home router VoIP has high priority, while file downloads do not. So _I_ can manage my bandwidth the way I want it. Once the packets go to the ISP, I don't hve control what will happen.
Still I think it's a concept that should be used, even if there is no guarantee that it's effective. (like the mouth-and-nose masks in time of Corona virus)

> I think it is hard to make QoS work in anything but extremely

I agree that is MIGHT help ;-)

[...]

Regards,
Ulrich

---

From: Ragnar Sundblad <[email-masked]>
Date: Fri, 27 Mar 2020 16:37:51 +0100

> On 27 Mar 2020, at 08:47, Harlan Stenn <[email-masked]> wrote:
> 
> 
> 

Very nice!

(Is it just me, or is there room for improvements of the documentation of
the pool directive in several of the implementations?)

Ragnar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 30 Mar 2020 10:19:58 +0200

> This has always been part of the 'pool' directive in the Reference

Are you sure it does that? If ntpd automatically replaced the worst
performing servers (e.g. by root distance or jitter), it would break
the load balancing of pool.ntp.org. It shouldn't be a default
behavior of clients using the pool. (With other pools it might be ok.)

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 31 Mar 2020 08:00:17 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 30.03.2020 um 10:19 in
Nachricht
<24990_1585556439_5E81ABD7_24990_85_1_20200330081958.GB17158@localhost>:
> On Fri, Mar 27, 2020 at 12:47:06AM ‑0700, Harlan Stenn wrote:
>> >> It would also make sense for sites that are up 24/7 to do something like

> once 

AFAIK, it work like this: ntpd picks a set of servers (say 6) and start using
them. Some of those may be flagged with '-' or may be unreachable. ntpd
replaces those with a new pool query to fill up the slots and the process
repeats.

I think the corresponding log messages (if loglevel macthes) are:
#sever pick a new host
21 Mar 10:40:14 ntpd[15087]: Soliciting pool server 172.20.16.4
#server drops a host
21 Mar 13:20:12 ntpd[15087]: 172.20.16.36 local addr 172.20.16.35 -> <null>

The example is manycast, but pools should be very similar.

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 31 Mar 2020 10:11:36 +0200

> replaces those with a new pool query to fill up the slots and the process

Replacing an unreachable source is ok (the pool.ntp.org monitor
removes unreachable servers from DNS). Replacing reachable sources
that have the '-' symbol (outlier) would not be ok. From a quick look
at the source code it doesn't seem to be doing that. However, it seems
it can use up to 20 sources simultaneously in order to get 3 sources
for combining. That's not a great default configuration for pool.ntp.org.

-- 
Miroslav Lichvar