Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Miroslav,

Please see inline ...

> -----Original Message-----
> From: Miroslav Lichvar <[e-mail]>
> Sent: 21 July 2021 10:18
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: Eric Vyncke (evyncke) <[e-mail]>; Warren Kumari
> <[e-mail]>; The IESG <[e-mail]>; draft-ietf-ntp-interleaved-
> [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-
> modes-05: (with DISCUSS and COMMENT)
> 
> On Fri, Jul 16, 2021 at 09:39:47AM +0000, Rob Wilton (rwilton) wrote:
> > Regarding the issue with the extension mechanism, another possible choice
> could be for the client to try and open two parallel sessions, one using a new
> extension field, and one without.  The client could then monitor the
> responses to the two sessions and choose whether to use the other with the
> extension or not.
> 
> To me that doesn't look like a very practical solution. It wastes
> bandwidth. SNTP clients use only one server and might not easily be
> modified to work with multiple associations. In case of a heavy packet
> loss, the client would be randomly switching between the two
> associations, or if it stuck to the interleaved mode once it was found
> working, it wouldn't fall back to RFC5905 if the server lost the
> support (e.g. after changing implementation implementation or
> reconfiguration), so it would have to restart the parallel association
> periodically.

I was assuming that a client would probably learn and maintain some historical state about whether a server at a given address has previously supported the new extension.  But I agree that it adds complexity.

> 
> Using a 28-octet extension field to convey a single bit of information
> is quite wasteful anyway.

Perhaps, but that is the mechanism that is available.


> 
> > Hence, I propose three possible alternatives:
> >
> > (1) Change this document to somehow make use of NTPs extension
> mechanism and continue down the path of publishing as a proposed
> standard.  This, I think, would probably entail taking the document back to
> the WG.
> >
> > (2) Change the document status to Informational rather than Standards
> Track, modifying the text to focus on documenting how some
> implementations work rather than as an endorsement from IETF that this is
> the right way to modify the NTP protocol.
> >
> > (3) Alternatively, if the authors/WG believe that publishing that document
> as proposed standard is definitely the right choice, then I would be willing to
> change my ballot position to abstain.  I.e., I don't agree with what is being
> done here, but neither will I block progression of the document, given that
> you say that this modification does not cause operational issues in practice.
> 
> If those are the only options, the preference of the WG seems to be
> the second one.

In case it is not clear, I'm only representing my individual view, not any sort of consensus of the IESG (but I am also aware that Ben and Warren have balloted abstain).  Hence, a 4th choice is to wait until the doc is on the telechat, all ADs have had a chance to ballot on it and perhaps verbally discuss it at the telechat.  I think this is waiting for Karen's shepherd writeup to be updated because it was for the wrong doc.  In fact, updating the shepherd writeup and waiting for all ADs to ballot and discuss is possibly the most sensible choice of action.  I.e., I don't want you to spend time updating it to informational only for some other ADs to decide that would not be sufficient, and hence you end up wasting your time.


> 
> Could you please clarify why you don't see the proposal as the right
> way?

I think that my objections really come down to two points:

(1) The protocol has an extension mechanism, but the solution is choosing not to use it.  I appreciate that the extension mechanism is deemed to be broken and NTPv5 is meant to fix it, but then I question why standardize this particular extension now, 10 years after NTPv4 was standardized.  I.e., presumably you could bake this enhancement into NTPv5 in a very clean way.

(2) It seems to be redefining the meaning of some of the protocol fields, not in a small way, and I'm not really sure that this is the right thing to be endorsing.  I.e., balloting "No objection" wouldn't really be right, because I do have an objection to what is being done here.

However, I balance those two points with:
 - I'm not familiar with NTP (but I noted that Daniel, who presumably does know NTP, seems to making similar arguments)
 - Some implementations are clearly doing this (and seemingly have been for a long time) and pretending otherwise doesn't really help.
 - You have explained/clarified that this interoperates with existing deployments.
 - You have explained that it doesn't cause additional operational complexity in practice.

... which is why I ended up with those suggestions above.


> Do you agree with the RFC5905 interpretation that Daniel Franke
> pointed out in his objection, that SNTP clients are free to put
> anything in the origin timestamp because the "An SNTP client can
> operate with any subset of the NTP on-wire protocol" doesn't have
> a MUST?

I really don't know the protocol, and I think that I would need to have a much better understanding of RFC5905 to give a properly meaningful answer here.  Looking back at Daniel's comments, I am somewhat persuaded that RFC5905 states that these fields can be ignored, and doesn't say what value field must contain if they are 'ignored'.  But equally, if the field had a non-zero value then would that not also mean that field is being used, assuming that there are no other bits in the packet to indicate whether the field has meaning?  Hopefully, clarifying this is in the plan for the next version of NTP ...
 
Regards,
Rob


> 
> Thanks,
> 
> --
> Miroslav Lichvar