Re: [Ntp] NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?))

[Mikkel Fahnøe Jørgensen <[e-mail]>]

We also have timestamp frames. That may be related to NTP.



Umm - where are these timestamp frames?

As to partially reliable streams. I am a big advocagte of these, but I do
not think that they are essential to time data because the payload - time -
is naturally providing a sequential marker. Thus you can avoid waiting for
QUIC v2 and you can avoid the additional complexity. The receiver can just
ignore receipt of out of order messages in, for example, datagram frames.
Datagrams do and do not have identifiers - the intention was not to remove
them, but to let the application provide them as early data in the frame.
If the connection only deals with NTP and you only have one unreliable
stream, you don’t even need an identifier because all datagrams implicitly
belong to the same stream.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 15 April 2020 at 02.16.10, Christian Huitema ([e-mail]) wrote:

We also have timestamp frames. That may be related to NTP.

-- Christian Huitema

On Apr 14, 2020, at 12:03 PM, Roberto Peon <[e-mail]> wrote:



I agree that Qv1 doesn’t have an ability to express this, since Qv1 doesn’t
allow for partial reliability except in extensions.
Regardless, if the requirement is to have no retransmission, then that is
the requirement, and should be (at least in a spec) written that way.


I’ll disagree on whether that is similar to datagrams. Datagrams don’t have
the same “address space” as does a stream, and there are certainly many
things out there that would prefer to have a stream-with-holes (i.e. an
address space that every party to the interaction agrees upon) than require
the application to do reassembly of everything (and caching) on its own.
This is really a separate conversation we can move somewhere else, though,
assuming it is work having at all!
-=R



*From: *Mikkel Fahnøe Jørgensen <[e-mail]>
*Date: *Tuesday, April 14, 2020 at 11:54 AM
*To: *Erik Kline <[e-mail]>, Watson Ladd <[e-mail]>,
Roberto Peon <[e-mail]>, Tal Mizrahi <[e-mail]>
*Cc: *IETF QUIC WG <[e-mail]>, "[e-mail]" <[e-mail]>, Lucas
Pardue <[e-mail]>, Spencer Dawkins at IETF <
[e-mail]>
*Subject: *Re: NTP is unique (was Re: QUIC as a transport substrate
(was:re-chartering: include DNS-over-QUIC?))



You don’t need the datagram extension, rather, you need a promise to not
retransmit or a promise to communicate the time in any retransmission.

I don’t understand this promise. In QUIC v1 you have streams, pings,
bookkeeping frames, and extensions. You cannot promise not to retransmit
something in as stream except by terminating the stream. Pings are not
suitable for conveying time information unless perhaps its mere arrival
acts a clock tick. You can of course create a new stream for each new time
event but it still doesn’t prevent retransmission unless you cancel, and if
you cancel, delivery of the payload is not guaranteed.



You could define a promise through a new extension with the desired
semantics but that is close enough to datagrams that it doesn’t make much
sense - but you might want a datagram that does not have ACKs - this
affects flow control, but since transmission is infrequent, that could work.



Something else:



It is hard to prevent an attacker from dropping or delay packets even on an
encrypted QUIC connection and a retransmission would not be a useful
mitigation, so I am not sure how you can make NTP truly secure. A voting
system from multiple sources could make such an attack more difficult.



Kind Regards,

Mikkel Fahnøe Jørgensen



On 14 April 2020 at 19.40.00, Roberto Peon ([e-mail]) wrote:

You don’t need the datagram extension, rather, you need a promise to not
retransmit or a promise to communicate the time in any retransmission.
While datagram provides, implicitly today, a promise to not retransmit,
datagrams themselves aren’t the requirement.
(Also, in the face of multipath, is it true that we won’t have duplicates
even for datagrams. I’m not sure this is clear right now?)

If the first packet has higher measurable (latency) overhead in the
processing stack, then you probably don’t want to use that one for NTP if
you’re high time accuracy.
In other words, you may find that you get better accuracy if you make a
connection, and then do the NTP “stuff”. Similarly, you may find you get
better accuracy if you **always** do a handshake on every packet (though
that is more expensive)…

While QUIC is a wonderful hammer, I do wonder if it provides any
significant benefit in this case.

-=R



*From: *QUIC <[e-mail]> on behalf of Mikkel Fahnøe Jørgensen <
[e-mail]>
*Date: *Monday, April 13, 2020 at 2:31 AM
*To: *Erik Kline <[e-mail]>, Tal Mizrahi <[e-mail]>,
Watson Ladd <[e-mail]>
*Cc: *"[e-mail]" <[e-mail]>, IETF QUIC WG <[e-mail]>, Spencer
Dawkins at IETF <[e-mail]>, Lucas Pardue <
[e-mail]>
*Subject: *Re: NTP is unique (was Re: QUIC as a transport substrate
(was:re-chartering: include DNS-over-QUIC?))



I think these observations on resource usage are correct, but changing
system time could be a significant attack vector. For NTP to make sense
over QUIC, the datagram extension would be needed to avoid much of the
state and retransmission overhead. A simplified implementation could even
forego a lot of the QUIC machinery such as streams and only rely on the
handshake and datagram. Of course you could also use DTLS but that is yet
another stack.



Kind Regards,

Mikkel Fahnøe Jørgensen



On 13 April 2020 at 11.23.06, Tal Mizrahi ([e-mail]) wrote:

Hi,

> > This came to mind because I had a silly idea. As I watched Christian's
presentation in dprive I thought (a) this DoQ doc really benefits from
Christian knowing what he's doing with QUIC, and (b) I wondered if I could
run NTP over QUIC. Like I said, this is probably silly and there might be
nothing to gain from the attempt, but it got me thinking about guidance for
anyone else with both (a) such an idea and (b) the time to write/implement
a proposal.

NTP-over-QUIC is an interesting idea.

The main benefits I can think of of running NTP over QUIC are enjoying
the inherent security of QUIC, and avoiding middlebox tampering.
I wonder if these benefits are worth the effort.

On the other side running NTP over QUIC may consume significantly
higher resources on NTP servers than are necessary today. NTP servers
try to minimize the per-client state (or keep it zero if possible),
while QUIC may require per-client state in order to allow 0-RTT. Also
the precision of NTP may be lower than existing implementations if
implemented in user space.

> You also don't want automatic retransmission in NTP, and the flow
> control is essentially nonexistent: it's driven by the synchronization
> loop.

One may consider using QUIC in datagram mode, and this would prevent
retransmissions. ACKs would still be sent in this case.

Cheers,
Tal.



On Mon, Apr 13, 2020 at 9:18 AM Watson Ladd <[e-mail]> wrote:
>
> On Sun, Apr 12, 2020 at 11:03 PM Erik Kline <[e-mail]> wrote:
> <chop>
> >
> > This came to mind because I had a silly idea. As I watched Christian's
presentation in dprive I thought (a) this DoQ doc really benefits from
Christian knowing what he's doing with QUIC, and (b) I wondered if I could
run NTP over QUIC. Like I said, this is probably silly and there might be
nothing to gain from the attempt, but it got me thinking about guidance for
anyone else with both (a) such an idea and (b) the time to write/implement
a proposal.
>
> NTP has a very unique property: one packet is sent every 1024 or 512
> seconds or so by the client. A single server can handle a high packet
> rate easily because of the statelessness. Adding state would start
> getting problematic at the high packet rates.
>
> You also don't want automatic retransmission in NTP, and the flow
> control is essentially nonexistent: it's driven by the synchronization
> loop.
>
> Getting through middleboxes isn't nothing! But that's more a new port,
> and ideally you want middleboxes to correct for packet queuing times.
>
> Sincerely,
> Watson Ladd
>