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

[Miroslav Lichvar <[e-mail]>]

On Mon, Nov 29, 2021 at 11:04:01PM -0600, Dan Drown wrote:
> 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 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.

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

I guess on public servers this extension would have only a minimal
impact. Of course it would depend on how it was implemented in the
clients, whether the client that had server functionality had it
disabled by default (if it could actually be disabled).

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

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.

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.

-- 
Miroslav Lichvar