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

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 1 Dec 2021 12:13:23 +0100

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 1 Dec 2021 12:13:54 +0100

On Mon, Nov 29, 2021 at 09:30:09PM -0600, Dan Drown wrote:
> Quoting Miroslav Lichvar <[email-masked]>:
> >       *  In the leap-smeared UTC, it is the current offset between the
> >          leap smeared time and UTC (former minus latter) using the
> >          time16 type (0x8000 if unknown).
> 
> I would be fine with that.  Does leap-smeared UTC need a (3) to identify the
> scale identifier?

Yes, good point. Thanks.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 1 Dec 2021 12:27:02 +0100

On Thu, Nov 25, 2021 at 09:47:48PM -0600, Dan Drown wrote:
> For the offset correction extension (5.5), are there any implementations of
> this? I've heard that it is harder to parse optional headers in asics,
> should this extension be required to be at a fixed location? something like:
> "if this extension is present, it MUST be the first extension field after
> the NTPv5 header"

That would probably be easier for implementation in hardware, but it
would cause a problem for authentication. The field would have to be
skipped when the authenticator is calculated. Is it worth the trouble?

I have no idea if anyone is actually willing to implement the
correction field. In any case, it will still be more difficult to
implement than the PTP correction field as NTP works with timestamps
corresponding to the end of the reception instead of beginning.

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Wed, 1 Dec 2021 09:14:13 -0500

>> "if this extension is present, it MUST be the first extension field after
No, it probably should be that last extension and not the first. 
Extensions should not, in general, be ordered. A correction like this 
should be after any MAC which does authenticate the packet so that this 
correction is included in the MAC.
> corresponding to the end of the reception instead of beginning.

See RFC8721. I believe that Tal did implement this.

Danny

---

From: Dan Drown <[email-masked]>
Date: Wed, 01 Dec 2021 22:26:11 -0600

> skipped when the authenticator is calculated. Is it worth the trouble?

Oh yes, you're right, correction would need to be at the very end,  
after any signature or NTS fields.

> corresponding to the end of the reception instead of beginning.

Wouldn't the middle boxes just need to measure queue latency from  
RX(first byte) to TX(first byte)? The gist you linked had the  
correction factor just adding latency in the request packet and  
subtracting latency in the response packet to result in the asymmetric  
latency that the client can use as a correction.

---

From: Dan Drown <[email-masked]>
Date: Wed, 01 Dec 2021 22:30:39 -0600

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

> (e.g. marked with the + symbol instead of *). It is a graph of

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.

> 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

---

From: Dan Drown <[email-masked]>
Date: Wed, 01 Dec 2021 22:43:56 -0600

Quoting Danny Mayer <[email-masked]>:
> Extensions should not, in general, be ordered. A correction like  
> this should be after any MAC which does authenticate the packet so  
> that this correction is included in the MAC.

I'm assuming you mean that the correction is not included in the MAC.  
I had not considered authenticated/signed packets, and I agree that  
the corrrection would have to be outside of any signature. But this  
restriction should probably be mentioned in the rfc.

>> [...] it will still be more difficult to

I'm assuming you mean RFC7821, but I don't see anything in it about  
adjusting hardware timestamps to match NTP's legacy of software  
timestamp measurements, just the parts needed to keep the UDP checksum  
consistent after changing the TX timestamp in the packet.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 2 Dec 2021 09:59:24 +0100

On Wed, Dec 01, 2021 at 10:26:11PM -0600, Dan Drown wrote:
> Wouldn't the middle boxes just need to measure queue latency from RX(first
> byte) to TX(first byte)? The gist you linked had the correction factor just
> adding latency in the request packet and subtracting latency in the response
> packet to result in the asymmetric latency that the client can use as a
> correction.

That assumes the correction field is supported on all network devices
between the server and client, or at least that all network links have
the same speed and the packet length doesn't change (e.g. due to
adding and removing VLAN tags). If that is not the case, the
correction will have an error due to the asymmetric link speed or
length.

In the NTPv5 draft this specific case is mentioned, but in general it
is required that the correction works with the end of the reception to
support networks where not all devices support the correction field.

This is in contrast to PTP which requires the support everywhere. That
is ok as PTP was specifically designed for full hardware support. But
in NTP I think it would be nice if switches in a network could be
upgraded only one at a time without breaking the assumptions.

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Thu, 2 Dec 2021 08:56:20 -0500

On 12/1/21 11:43 PM, Dan Drown wrote:
>> should be after any MAC which does authenticate the packet so that 
>> this correction is included in the MAC.
>
Yes.
> consistent after changing the TX timestamp in the packet.
Yes, RFC7821. That was exactly what Tal was doing.

Danny

---

From: Doug Arnold <[email-masked]>
Date: Thu, 2 Dec 2021 17:20:16 +0000

Just to be clear: PTP does not require that all switches are PTP capable.  The ITU-T G.8265.1 and G.8275.2 profiles explicitly assume that there is no or only partial timing support in the network path.  Financial data centers often do not need on-path support since their networks are designed for minimum latency.

Practically speaking, in long network paths, it would take only one busy router with no timing capability to render the correction field irrelevant. The Correction proposed for ntpv5 would probably be most useful for site local use cases, at least at first.  But if it became common for switch and router vendors to implement this feature, then WAN timing would gradually become more precise.

Doug

From: ntp <[email-masked]> on behalf of Miroslav Lichvar <[email-masked]>
Date: Thursday, December 2, 2021 at 3:59 AM
To: [email-masked] <[email-masked]>
Subject: Re: [Ntp] comments on draft-mlichvar-ntp-ntpv5-03 / Extension fields

--
Miroslav Lichvar

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 6 Dec 2021 10:15:15 +0100

> Just to be clear: PTP does not require that all switches are PTP capable.  The ITU-T G.8265.1 and G.8275.2 profiles explicitly assume that there is no or only partial timing support in the network…

I guess I should say "required to perform well".

Yes, technically speaking, PTP will work in a network without full PTP
support, but it was not designed for that (it breaks the assumption
about delay being mostly constant) and generally will not work as well
as protocols that were designed for real computer networks like NTP.

Also, the PTP support in switches is not just about being present or
not. It must be reasonably well implemented. I know that in some cases
it had to be disabled as it actually made things worse.

> Practically speaking, in long network paths, it would take only one busy router with no timing capability to render the correction field irrelevant. The Correction proposed for ntpv5 would probably…

Right.

-- 
Miroslav Lichvar