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

[Dan Drown <[e-mail]>]

Quoting myself:
> for the reference id extension (5.3):
> * I'm assuming if the client wants to receive it in the response, it  
> has to send an empty one in the request.
> * I'm not an expert at bloom filters, but with 16 stratums, I think  
> we want one at least 160 bits and to set 7 bits for each clock (1%  
> false positive rate).
> * Because we don't actually need the random ID values themselves,  
> instead of generating a random ID and hashing it, we can just  
> generate 7 random numbers between 0..159 and set that bit.
> * Detecting a loop would involve checking to see if our 7 bits are  
> set in the data from our upstream source

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

* I need to consider compatibility between NTPv4 refid and v5  
extension. Specifically, what translations happen when switching  
between versions

* The 1% false positive rate would be a problem when you have a set of  
servers each with 10,000+ clients

* Packet logging for monitoring and management would be challenging

* Operators would probably want some way to make this more  
deterministic, maybe a configured local ref id

I'm doubting if a bloom filter is the right choice for NTP loop detection.