Re: [chrony-dev] NTP "extended information" draft WIP implementation

[Will Miles <wmiles@xxxxxxx>]

On 2017-10-06 6:12 AM, Miroslav Lichvar wrote:
> On Thu, Oct 05, 2017 at 05:44:36PM -0400, Will Miles wrote:
> > Hi,
> >
> > Attached is a patch sequence for implementing Harlan Stenn's draft "Extended
> > Information" NTPv4 extension as a mechanism to distribute TAI offsets
> > between nodes.   This should be considered beta quality at best - it hasn't
> > been thoroughly debugged, and there is undoubtedly significant room for
> > improvement.
> Thanks. This is great stuff. When I want to include some of the
> patches, I'll ask for updates :).

Thank you!  I'm keeping the current WIP up on github at 
https://github.com/willmmiles/chrony/commits/draft-extended-information 
, but once I ship it'll probably just languish until something breaks.

> > -> It might've been better to add a runtime configuration file option
> > instead of a compile time decision to enable the draft extension support.
> Yeah, current NTP implementations cannot respond properly to a request
> with an (unknown) extension field.
>
> I'm wondering if sources should vote on the TAI offset as with the
> leap status. It will be interesting to see how this works around leap
> seconds.
>
> > -> I didn't spend a lot of time considering which outbound packets ought to
> > have the extension added - the decision there is very likely wrong for the
> > general case.
> I think server responses should include the field only if the client
> requests have it.

I modified the reception to only reply if the request carried the field; 
and transmission to only send in client mode (and not carry the client's 
TAI value, for security), both enabled via a global config option.   As 
I type this, though, I realize that's probably still not quite right -- 
it should probably be a per-server option.   One more try!

I thought about implementing a voting mechanism parallel to what you did 
for leap second status, but I couldn't come up with a trivial 
implementation quickly.   The leap second status has only 3 possible 
states (+1, -1, or unchanged), but the TAI offset would need to deal 
with an arbitrarily long list of possibilities - in the worst case, 
every source could give us a unique, different value.  I balked at 
trying to manage dynamic allocation in the context of SRC_SelectSource.

Further TAI-related thoughts:

Should the last known TAI offset be recorded with the drift stats?
Does tzset() cache the tzdata in memory?   If so, long-running systems 
may need to restart chrony on tzdata update to pick up new table values.
Can we query the tzdata for the TAI table expiry time?  I know it's 
carried in the underlying leap-seconds.list file.   With the expiry time 
on hand, we could know when to trust our local information vs remote 
updates.


> Some random comments:
>
> I'm not sure if it will be generally possible to pad any extension
> field up to the minimum length as they may be specified to have a
> variable length. This is one of the unresolved issues that the NTP WG
> needs to address.

Fair enough.   Honestly the RFC7822 patch really made me uncomfortable, 
too -- I don't understand the rationale behind the padding rule, it 
comes off like an attempt to be backwards compatible with some shipping 
but broken implementation.   An alternative would be to insert a 
specialized "padding" extension field, but that has its own issues with 
the other end maybe rejecting it on the grounds it doesn't recognize 
it.    That's really why I broke it out to a separate patch.

> When making an incompatible change in a cmdmon request/response, the
> command number should be changed.
Noted.   I had mistakenly thought that since the change adopted one of 
the reserved fields without changing the length, old servers would 
zero-fill it (which just so happens to be the 'don't know' value) and it 
could be safely treated as backwards compatible.  I will correct this.

-Will


--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.