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

[Dan Drown <[e-mail]>]

Quoting Miroslav Lichvar <[e-mail]>:
> I guess a more common problem (at least for public servers) is traffic
> cost, which may scale linearly with the packet length.
>
> NTS tripled the packet size and I don't remember many complaints about
> that. It could do better in that aspect, e.g. the unique ID is not
> really necessary when TX timestamps are fully randomized, but I
> understand people wanted it to be independent.

Perhaps NTS and NTPv5 will be a small enough % of people's traffic
that they won't notice the difference in terms of bandwidth usage.
There's a lot of SNTP and legacy NTP clients that haven't been
updated in years and will likely stay that way.

> Wouldn't this be limited to a chain of IDs, assuming only one server
> per stratum?
>
> The idea for NTPv5 was to detect loops over all servers used for
> synchronization, including those that are not the best selected source
> (e.g. marked with the + symbol instead of *). It is a graph of
> servers.

Ah, you're right. My proposal would be limited to just the primary
path. If the goal was to cover all sources, then a bloom filter would
be a much better choice.

> The bloom filter was proposed by Daniel Franke in his NTPv5 sketch:
> https://gist.github.com/dfoxfranke/4ca0443b6ff6e0473578cf3827b9ea7f
>
> I liked the idea and put it in my draft as it should be much more
> efficient than distributing the whole draft.

Ok, that's gist is an interesting proposal. My takeaways:
* source_seqno used as a bloom filter generation id and is in the main  
timestamp request/response to let clients know when to update
* bloom filter request/response are different modes seperate from the  
main timestamp request/response
* 128 bit client ID and 4096 bit bloom filter are much bigger than I  
was thinking, but should have less false positives