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

[Tal Mizrahi <[e-mail]>]

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
>