Re: [Ntp] comments on draft-mlichvar-ntp-ntpv5-03 / Extension fields

[Dan Drown <[e-mail]>]

Quoting Miroslav Lichvar <[e-mail]>:
> On Fri, Nov 26, 2021 at 09:48:20PM -0600, Dan Drown wrote:
>> After a day of thinking about my proposal above, I have the following
>> concerns:
>>
>> * The added packet size, 20+4 bytes is very large for NTP
>
> What would you consider the maximum acceptable size? Please note that
> only clients serving time to other servers would need to use it.
> Clients that don't serve time, which I think is the most common case,
> don't need to care about loops.

Taking an embedded NTP server with a 100M ethernet link for example,  
my concern is that adding 24 bytes reduces maximum packets per second  
from 109.6kpps to 90.6kpps (17%). The number of NTP servers on a 100M  
link doing near maximum packet rate is probably a short list, but it  
is a tradeoff to consider. I don't really have a set acceptable size  
and I am open to increasing the size by some amount for this  
functionality.

I agree that only NTP servers would need to care about loop  
prevention. So that would help the average packet size needed given a  
mix of clients and downstream servers.

> As you pointed out, it should be even much larger if we want a lower
> false positive rate. But it doesn't have to be transmitted all at
> once. The client could get it in multiple parts over multiple requests
> (e.g. 4 or 8). This would add a delay to the loop detection.

I'd be worried about keeping that data in sync between systems. Having  
a "generation" identifier would be one option to handle that. If we  
went that route, why not just have static IDs for each stratum instead  
of a bloom filter?

Something like:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length=12         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| generation    | stratum       | bits47..32                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bits31..0                                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

request would set everything to 0 and then give the stratum it wanted (1..16).

response would set a generation ID that changes every time the  
upstream clock changes. The generation ID changing would signal to the  
downstreams that they need to refetch all the refIDs. The downstreams  
could cache the data as long as the generation ID stayed the same.  
Each stratum would have a random 48 bit number identifying it.

For generation ID size, I picked 8 bits arbitrarily. That risks  
wrapping when the requestor is polling at 1024 seconds and the  
responder is changing references every 4 seconds. Stratum only needs  
to be 4 bits (0..15), so generation could be 12 bits instead, trading  
longer wrap times for slightly more implementation complexity.

If I properly understand the birthday problem in statistics,  
1-e^(-n*(n-1)/(2^(48+1)))>0.001 is the estimate for how many servers  
you need before you have a 0.1% chance of two of those servers picking  
the same 48 bit number (assuming fully random id selection). Which is  
750,488 servers, so that seems unique enough to me.

A 12 bytes extension field is a 10% reduction in maximum packets per  
second vs 24 bytes' 17%.

There would have to be some sort of reserved ID for the case where a  
responder didn't know the data of a given stratum yet (or NTPv4 was  
involved in the path). Maybe 0xffffffffffff.

I'm not sure if I've fully explained this, let me know if there are  
any questions.

>> * I need to consider compatibility between NTPv4 refid and v5 extension.
>> Specifically, what translations happen when switching between versions
>
> Most of the information would be lost if an NTPv4 server was in the
> chain. This would be common in the beginning. For NTPv4->NTPv5
> compatibility, we could specify a mapping of the 32-bit refids to the
> bloom filter.

It could be mapped directly onto bits31..0

>> * Packet logging for monitoring and management would be challenging
>
> You mean manually checking whether a server is in the filter?

For diagnosing "why did things break" after the fact, it would be nice  
to have a log of this data somewhere

>> * Operators would probably want some way to make this more deterministic,
>> maybe a configured local ref id
>
> It could be saved to disk to not change across service restarts.

I guess I'd rather see it in a config file than a generated state  
file. If no config for the ID is present, it would be automatically  
generated each time.