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

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


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.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/