[Ntp] Antw: [EXT] Re: CLOCK_TAI (was NTPv5: big picture)

[Ulrich Windl <[e-mail]>]

>>> Martin Burnicki <martin.burnicki=[e-mail]> schrieb am
06.01.2021 um 15:18 in Nachricht
<[e-mail]>:
> FUSTE Emmanuel wrote:
>> Le 06/01/2021 à 11:50, Martin Burnicki a écrit :
>>> Philip Prindeville wrote:
>>>>> On Jan 5, 2021, at 9:09 AM, Martin 
> Burnicki<martin.burnicki=[e-mail]>  wrote:
>>>>>
>>>>> For NTP, things are different. There is a huge base of NTPv4
>>>>> installations, and making NTPv5 basically compatible with v4 would IMO
>>>>> strongly increase the acceptance of NTPv5.
>> The "basically" mean nothing. Is is 100% compatible or not compatible. 
> 
> As I tried to explain in earlier messages, you can easily make it fully
> compatible and support new features by extensions.

I still think the v4 extension field mechanism was a big mistake and the
mechanism should be redone for a clean design.
So v4 should remain v4 and v5 should be something better.

> 
>> It is NTPv4 or NTPv5.
> 
> In the first place it is NTP. If you think you need to completely
> redesign it, just give it a different name.


Do you see "NTP" as "packets" only? I think "packets" can be changed easily;
they are just the representation of information, not the information itself.

> 
>> The "not so different" between v3 and v4 was much 
>> a source of problems than an adoption catalyst.
> 
> I'm working with NTP for a very long time now, and I don't remember any
> problem when moving from v3 to v4. Exactly the opposite was true: there
> were no problems because the protocol was compatible to a very high
> degree, so it was no problem to have a mixed v3/v4 environment an slowly
> changeover to v4. And according to my job I've seen *many* different use
> cases, both for the client and for the server side.
> 
> So which problems exactly do you mean?
> 
>> I even view it in the opposite for a psychological/marketing acceptance 
>> point of view: being  v4 compatible is so restrictive for v5 that people 
>> would prefer to stick to v4 as v5 would give nothing more than v4 
>> (unless being an expert to understand the difference/gain).
>> Do we want to do a NTPv4 revision or NTPv5 ?
> 
> IMO the protocol should evolve from v4 to v5 in a compatible way.
> 
> As I already mentioned before, I've seen real incompatibility problems
> when PTPv2 was introduced because even the base packet was incompatible
> with v1. Luckily this wasn't a too big problem because PTPv1 wasn't
> widespread when v2 was introduced.
> 
>>>> The logical corollary to this argument is that because there ARE a lot of

> servers, it’s not unreasonable to think that there will be a lot of both 
> NTPv4 and NTPv5 servers co-existing in the future, and the user is free to 
> peer with either.
>>> So you think it's not necessary to upgrade v4 nodes to v5, as it has
>>> been done from v3 to v4? Simply systems should stick with v4 and only
>>> enhanced system should start using v5?
>>>
>>> In this case, wouldn't it be better to start defining a completely new
>>> protocol and e.g. call it "Extended Time Protocol", which can be chosen
>>> instead of NTP? This would be similar to PTP, which you can use instead
>>> of NTP. ;-)
>>>
>>>> Which eliminates the need for NTPv5 servers to also speak NTPv4.
>>> If you have a large network with different types of client you will need
>>> to provide NTPv4 and "ETP" (AKA NTPv5) if NTPv5 has requirements that
>>> are not needed and can't be supported by some clients.
>> But the "can't" is wrong as long as the offset is always transmitted and 
>> for the "need" argument, the same clients would have stick to 
>> time/daytime service if it is a real one.
> 
> Sorry, but you are competing apples to peaches. Do you really suggest
> that NTPv4 clients fall back to time/daytime (which, by the way, are
> also different protocols than NTP) ?
> 
>> A v5 server could still provide v4 frame and for v4 clients if needed 
>> but without hw times-stamping support which it would reserve for v5 
>> clients if it has some actives. But it is implementation and policy
details.
> 
> I think whether hardware timestamping is supported or not isn't related
> to the packet format. Even NTPv4 can use timestamping in the kernel
> driver, if the OS supports it.
> 
> 
> Martin
> -- 
> Martin Burnicki
> 
> Senior Software Engineer
> 
> MEINBERG Funkuhren GmbH & Co. KG
> Email: [e-mail] 
> Phone: [phone]
> Linkedin: https://www.linkedin.com/in/martinburnicki/ 
> 
> Lange Wand 9, 31812 Bad Pyrmont, Germany
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
> Andre Hartmann, Heiko Gerstung
> Websites: https://www.meinberg.de  https://www.meinbergglobal.com 
> Training: https://www.meinberg.academy 
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp