Re: [Ntp] Antw: Re: Antw: [EXT] Re: Quick review of WGLC for status change for draft-ietf-ntp-update-registries

[Harlan Stenn <[e-mail]>]

On 8/18/2022 1:36 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <[e-mail]> schrieb am 17.08.2022 um 23:44 in Nachricht
> <[e-mail]>:
>> Miroslav,
>>
>> Sometimes I have trouble taking you seriously.
>>
>> On 8/17/2022 6:24 AM, Miroslav Lichvar wrote:
>>> On Wed, Aug 17, 2022 at 02:30:20AM -0700, Harlan Stenn wrote:
>>>> I believe that's what has already been done.  For the timing modes:
>>>>
>>>> v2 to v3 changed a variable in the packet header.
>>>
>>> So if a v2 server responded to v3 request with v2 data in v3 packet,
>>> the client would get incorrect data?
>>
>> There are slight differences in the data content between v2 and v3.
>>
>> In v2 the 2nd word is Synch Distance and the 3rd word is Synch Dispersion.
>>
>> In v3 and beyond the 2nd word is Root Delay and the 3rd word is Root
>> Dispersion.
>>
>> None of these changes are operationally significant.
> 
> So why were the packet fields renamed then? I guess the algorithms to set them up did change, too.

I think I've said this before.

Because Dave treated the RFCs as "the best information at that moment in 
the development of NTP".  NTP has continued to evolve, after the 
publication of the RFCs.

The same was true for NTPv1, v2, and v3.

As I recall, Dave changed "jitter" to "dispersion" somewhere in there, too.

The goal of the NTP Project is to evolve and improve the quality of 
synchronized network time.  The goal is NOT to slavishly implement an 
outdated specification.

Now if enough people WANT a version of NTP that accurately and 
faithfully implements the v4 RFC, that's certainly doable.

But our experience is that people want their clocks sync'd as well as 
possible, so they want the improvements we make.

>> Do you disagree?
>>
>> And this change was made over 30 years' ago.
>>
>>> I thought you said the idea was to add new fields if incompatible
>>> changes are made.
>>>
>>> In case you forgot, v2 was not compatible with v1 either.
>>
>> Different.
>>
>> In v1 the 3rd word is Estimated Drift Rate.
>>
>> In v2 and beyond the 3rd word is Synch Dispersion.
>>
>> OK, in v1 the 2nd word is Estimated Error and in v2 and beyond the 2nd
>> word is Synch Distance.
>>
>> None of these values are used in the basic time calculations.
> 
> But "estimated error" is used to set the client's clock (via timex.h interface), right.

Yes.  From clock_jitter.  Which is maintained based on local 
observations, not from data received from client packets.

> An of the "mode 6" side it's even more adventurous:
> Some time "phase" became "offset", "error" became "noise", "freq" became "frequency" (with a different unit),
> "rootdispersion" became "rootdisp", "noise" became "clk_jitter" (I guessed), "jitter" became "sys_jitter", "stability" became "clk_wander", "poll" became "tc". (Using mode 6 for monitoring is a real adventure, specifically as there is no (or little?) documentation on the variables being used).

Yes, and:

- name changes are not a fatal problem, as I discussed in my emails
   with Heiko.  If one really cares, one can detect and accommodate
   these name changes.

- by observation, nobody has cared about this before now, to the
   degree that any attempt has been made to codify this.

On this last part, how would one expect to standardize on the variable 
names in the protocol document if the algorithms were in a separate 
document?

> OK, it's easy to say the packet format is still the same, but does it really help?

Does it hurt?

What is the goal?

Please compare the situation with NTPv[234] and those upgrades, with how 
things will play out with the proposed v5.

>> And this change was made/codified over 33 years' ago.
>>
>>>> v3 to v4 added extension fields.
>>>
>>> As Ulrich already explained, that works only for the v3-subset of the
>>> protocol, i.e. the same is if the protocol number didn't change.
>>
>> OK.  What's your point?
>>
>> Do you agree that a v4 packet without EFs is equivalent to a v3 packet?
> 
> The packet yes, but won't the frequently cited "pulse response" be different?

 From what, v3 to v4?  Possibly.  But "different" can be the same, 
better, or worse.

And if the behavior of the latest v4 code is no worse than (or in any 
cases, better than) what is described in the RFCs, who cares?

If one wants exact 5905 behavior, one can certainly pour over the code 
to find the instance of the code that will best give that to them.  To 
date, NOBODY has asked for that.

>> If so, that's 100% compatibility.
>>
>> What problem do you see?
>>
>>> A v3 server is not able to respond to a v4 request containing
>>> extension fields, even if it's authenticated with a symmetric key that
>>> the server knows.
>>
>> So what?
> 
> That means the client has to keep different implementations per protocol version, making the whole discussing a bit useless IMHO.
> Just "chopping off the extras that were added later" doesn't really work.

Who is suggesting this?

The code implements "respond with the version we were sent".

If a v3 server gets a v4 query:

- If the v4 query contains an EF, the server will drop it
- If the v4 query contains no EF, then
- - if there is no authentication, the server will respond with
     a packet identified with v4 and no authentication.  The client
     should be fine.  This happened a LOT from 1997 thru 1999,
     tapering off after that.
- - if there is authentication and that failed, the packet would
     dropped.  As expected.
- - if there is authentication that passed, the server will
     respond with a packet identified with v4 and (correct)
     authentication.  All should be well, and this almost certainly
     happened a LOT from 1997 thru 1999, tapering off after that.
>> The only EFs that have been 0-day supported by v4 have been autokey EFs.
> 
> What does that mean, "0-day supported"?

Part of the initial release of ntp-4.

> You sent it out to the public, but then say nobody should use it as it is broken and there is not easy replacement? You can safely assume that those EFs will be "ghosting around" for years.
I find your statement to be disingenuous.

Autokey was written for a very specific purpose, and it served that 
community sufficiently for over a decade.

As for the "no easy replacement", sometimes reality bites.

If NTF had any of:

- volunteer help of sufficient quality
- funding of sufficient quantity

we'd all have a solution.

It's not my personal responsibility to do all of these things.

 > I think the whole autokey stuff wasn't really ready for public; 
instead it was a kind of public beta test that was canceled soon.

You are entitled to your opinion.

>>
>> If the v3 server authenticates with a symmetric key, there will be no
>> problem.
>>
>> v3 *does not describe EFs*.
>>
>> v3 went EOL in November of 1998.
>>
>> Why would a v4 client decide to send an EF to a v3 server?
> 
> Because id does not have separate implementations for each protocol version?

Seriously?

That has nothing to do with it.

I don't believe you have thought this thru.

>> Is what you describe a real problem?  If so, how significant is it?
>>
>> I guess I'm really asking what your goal is.
>>
>>>> As I have said many times, the design of the timing modes and the packet
>>>> structure allows NTP to reply to packets of lesser, equal, or greater
>>>> version numbers and "it just works".
>>>
>>> No, it doesn't. You may think it works, but you just don't see the
>>> whole picture.
>>
>> Then please sufficiently describe the actual problem(s).
>>
>>>> Your NTPv5 work is explicitly breaking that rule, and y'all are apparently
>>>> only recently beginning to see some of the consequences of that choice.
>>>
>>> That rule isn't written anywhere and as you just shown, it wasn't
>>> followed anyway. Why should be v4->v5 be different?
>>
>> Please support your claim that the changes in the past were
>> operationally significant.
>>
>> Please show how your claim that what you have proposed for v5 changes
>> are similarly operationally (in)significant.
>>
>>>> It's not clear to me what or how long it will take for a v5 client to detect
>>>> and remediate an attempt to talk to a v4 server.
>>>
>>> If you read the draft, you would know there is no additional delay.
>>
>> So what delay is there?  I'm trying to avoid spending time slogging thru
>> a significant document to obtain a small piece of information.
> 
> Harlan, we all read a lot of documents over and over...

I'm happy for you.  I don't have that kind of time.

>> And the v5 work that I have see is all about "rough consensus" and, to
>> date, nothing about "working code".
> 
> I think that is how software should be done: First have a concept, them implement it, the revalidate the concept, maybe just to decide whether the concept has a flaw or the implementation of the concept. Possibly NTP developement worked the other direction in the past (first implement, then specify).

I don't understand.

Is there a public repository of v5?  Are there status reports about how 
it behaves when getting requests from a v4 (or earlier) server?

I see a LOT of talk here about new issues and what will probably work to 
fix them.

I have not seen discussions about how there is code to actually show how 
it behaves.

> However if you want to promote different competing implementations the "design first" has clear advantages.

Sure.  And that's how all previous NTP versions evolved.  Design and code.

What I've seen on NTPv5 is "design by committee" and no code.

>>>> It's not clear to me what or how long it will take a v4 client to detect and
>>>> remediate an attempt to get time from a v5 server that does not respond to
>>>> the v4 request.
>>>
>>> As was said multiple times, a v5-only server cannot respond to v4
>>> requests. The same as a v4-only server following RFC5905 cannot
>>> respond to a v3 request and the same as a v3-only server following
>>> RFC1305 cannot respond to a v2 request.
>>
>> That doesn't clearly answer my question.
>>
>> This goes to "how easy will it be to deploy your proposed v5 solution".
> 
> Maybe a significant part of the NTPv5 specification should handle the "protocol gateway", i.e.: how to handle requests from older NTP versions and how to send requests to older NTP implementations. Thinking this is not a problem to care about is simply wrong. Specifically if an implemenewr just wants to implement the currenct version, the rest of the document does not have to be "polluted" with all the compatibility stuff.

OK.

>>>>>>> Are there any client implementations using the NTPv4 control mode?
>>>
>>>> If that is, indeed, what you are asking, then no, I'm not aware of anything.
>>>> But how does that matter?
>>>
>>> It gives us an idea how important it is to have it specified.
>> I think you removed too much context in there.
>>
>> And I don't see the correlation between "client implementations using
>> the NTPv4 control mode" and "how important is it to specify the control
>> modes".
> 
> The control protocol _is_ important for remote monitoring. I guess that is why it was designed and implemented (even if "ad hoc").

I'm not sure I agree about the ad hoc part.  See my points above.

Otherwise, I hear you.  And my points remain:

- it's mostly useful for monitoring local servers
- nobody has bitten the bullet and made this easier to use.

And I don't see how the mode 6 plays in to the status of 
draft-ietf-ntp-update-registries, unless it shows that the proposed 
document does not address mode 6.

> Regards,
> Ulrich
> 
> 
> 

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!