Re: [Ntp] NTPv5: big picture

[Philip Prindeville <[e-mail]>]

> On Jan 4, 2021, at 11:00 AM, Magnus Danielson <[e-mail]> wrote:
> 
> Philip,
> 
> On 2021-01-04 18:40, Philip Prindeville wrote:
>> 
>>> On Jan 4, 2021, at 8:18 AM, Miroslav Lichvar <[e-mail]> wrote:
>>> 
>>> On Thu, Dec 31, 2020 at 06:54:40PM -0800, Hal Murray wrote:
>>>> Do we have a unifying theme?  Can you describe why we are working on NTPv5 in 
>>>> one sentence?
>>> There is a list of issues in NTPv4 I would like to see fixed in NTPv5:
>>> https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues
>>> 
>>> A major issue is that NTPv4 doesn't support short extension fields due
>>> to conflicts with legacy MACs, so fixing all those issues by adding
>>> new extending fields to NTPv4 seems impractical. Some things, e.g. the
>>> timescale selection, makes more sense to have in the header.
>>> 
>>>> Part of the motivation for this is to enable and encourage OSes to convert to 
>>>> non-leaping time in the kernels.  Are there any subtle details in this area 
>>>> that we should be aware of?  Who should we coordinate with?  ...
>>> I don't think that should be the job of the NTP WG. The kernels will
>>> need to support a leaping UTC timescale for as long as it is needed
>>> for civil time.
>> 
>> I disagree.  The kernel doesn’t inherently require UTC.  It could just as easily use TAI or some other format.
>> 
>> The kernel needs to provide into user-space some format which is then convertible to UTC, for as long as UTC is in-use by applications.
>> 
>> This could be handled by libc.
> 
> While I agree that kernel very well could operate in some suitable TAI
> format, and the PTP scale would be the low-hanging fruit for that, as it
> intends to be that blend of TAI and classical UNIX/POSIX time_t.
> 
> However, the only way I know with spreading in which TAI and UTC is
> maintained is through the kernel interface provided by the NTP
> nanokernel, and that is supported on effectively most Linuxes.
> 
> What can be done better is to use it properly and that libc would
> provide the needed glue. If libc does that, then from the user's point,
> if this is done completely in libc or shared between kernel and libc the
> user do not care, as long as they get correct time-stamp and the machine
> is setup to feed the needed data.
> 
> But then again, I do not think it's the NTP WG job do decide where it is
> implemented, rather we shall make sure the NTP side of things can
> support the needed features so that it works well.
> 
> Cheers,
> Magnus


It might not be our job, but by wearing many hats we can ease or even accelerate adoption.

When I was trying to get RFC-2597 and 2598 into widespread use in Internet traffic, I had to submit a PR glibc to get the IPTOS_DSCP_* definitions included, the IPTOS_CLASS_* definitions for RFC-2474, etc.

Then I (personally) wrote PR’s for Thunderbird, Firefox, Proftpd, Apache/APR, Sendmail, Postfix, Cyrus IMAPD, and yes, NTP, etc. and painstakingly ushered them through the integration process.  Often there were questions that needed to be addressed about why marking traffic for “high latency, high throughput” wouldn’t cause them to be disadvantaged as SLA-oriented provisioning was rolled out (there were a LOT of misconceptions about QoS).  I had to explain that traffic with no markings or default markings often would get the “whatever happens to be left” bandwidth category which could dynamically shrink to zero, and wasn’t where anyone wanted to be.  Sometimes having the same discussion over and over again in different forums.

Today a lot of traffic is correctly marked with the appropriate DSCP QoS that wasn’t 15 years ago when I started on this quest (well, to be honest the quest started 5 years before THAT when I was part of the Cisco initiative to make IOS-based routers and firewalls have bounded jitter so they’d be VoIP and IPTV-friendly).

My point is this: a necessary part of getting a new standard adopted is evangelizing its benefits, and removing its obstacles.

The work doesn’t stop when the standard gets published, or even a couple of interoperating implementations get released…

Does the WG collectively own this extra work?  No, that’s outside of our scope.  Do individual members of this WG have a higher probability of making the WG succeed if they apply that practical understanding of the problem into the world at large?  Most definitely.

-Philip