Re: [Ntp] Comments on draft-mlichvar-ntp-ntpv5-00

[Miroslav Lichvar <[e-mail]>]

On Tue, Nov 24, 2020 at 11:51:59PM +0000, Doug Arnold wrote:
> Regarding the document draft-mlichvar-ntp-ntpv5-00.  Great start.  I attach a file with suggestions and questions.

Thanks for the comments and suggestions. I made some of them in the
github repo:

https://github.com/mlichvar/draft-ntp-ntpv5

Please feel free to submit PRs and/or issues. If you, or anyone else,
would like to write new sections or make other substatial changes,
co-authors are welcome.

I'll reply to some of the comments in the rest of the mail:

> I propose giving the specified datatypes names so that they can be
> referred to later in the document: time16, time32, time64

The two shorter types don't contain timestamps, just some values in
seconds, so I don't think a time16/32 name would work well.

> Is UT1 used with NTP?  Perhaps we can leave this one out?

Here is an example:
https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination

> Propose changing: 

> The extension field MUST be the last extension field in the message
> unless an extension field is specifically allowed to be placed after
> a MAC or another authenticator field.
>
> To:
>
> The extension field MUST be the last extension field in the message
> unless an extension field is specifically allowed to be placed after
> a MAC or it is followed by another authenticator field.

Do you have any use case for having multiple authenticators in the
packet? I'd rather avoid unnecessary complications.

> Propose the following description of using the correction field:

> The Correction Extension Field is of type time64.  It is set to zero
> upon transmission by a client.  Any switch or router, that the
> packet traverses on the way to the server MAY add the value of the
> dwell time of the packet in that node to the correction value.  

The Correction Extension Field needs to include more fields. It needs
to be able to correct both offset and delay. It should also allow the
sender to fix the UDP checksum after the header is already sent, and
possibly also provide better resolution for the timestamps. Please see
this old draft:

https://www.ietf.org/archive/id/draft-mlichvar-ntp-correction-field-04.txt

I was planning to adapt it for NTPv5.

> I recommend against having two ways to do the same thing.  It makes
> the protocol more complicated without increasing the functionality.
> I suggest either staying with interleaved mode as a means of
> achieving two step precise timestamps, or deprecating interleaved
> mode, and recommending follow_up packets.  In this case I mean
> deprecated as allowed, for backward compatibility, but not
> recommended in new implementations. 

I agree it would be better to have a single way for this, but I don't
think one is clearly better over the other. They have different
requirements, which work differently in software and hardware server
implementations. 

The interleaved mode requires server to keep a client-specific state.
A microcontroller with a tiny amount of memory couldn't support a
large number of clients.

The follow-up mode is wasting network bandwidth and possibly also the
timestamping rate. A synchronous operation (waiting for the transmit
timestamp before handling another request) significantly reduces the
maximum response rate of the server. An asynchronous operation
requires memory, i.e. not an advantage over the interleaved mode.

-- 
Miroslav Lichvar