[ntpwg] KoD 'backoff' BCP/direction

[Brian Haberman]

Todd,
      I agree that there are people in the world (e.g., auditors) that 
need a different mechanism than NTPv4.  However, we are not chartered to 
develop this *new* time protocol.  We are chartered to publish the NTPv4 
specification.  I would highly encourage *anyone* who sees new 
requirements for time synchronization to get fully engaged in the TICTOC 
effort and help structure their approach to address these new 
requirements and/or usage models.

Regards,
Brian

TS Glassey wrote:
> Folks
> I think the biggest problem we are running into is that NTP is a utility
> that has become critical for proper operations of systems meaning that its
> now more important to Auditors than to the Physicists who designed the idea
> of NTP.
> 
> The problem is that Auditor's need something much different than what you
> folks are arguing about and its actually kinda funny watching the blind lead
> the blind here. But before anyone here starts making proclamations as to
> what NTP needs you need to establish the viewpoint perspective of the person
> uttering that commentary since if its not from an Auditor - it should ONLY
> be about the precision of the time data moved about a network.
> 
> Personally the Status Process and all of the communications between the 
> Server and the Client querying it should be through a Tunnled TCP connection 
> and not NTP's UDP periodic packaet stream. I would use XML messaging too to 
> insure that the messages can be properly managed as well.
> 
> And YES David - I think Danny is right here, but even his work should be 
> optional in the implementaiton.  By the way - SNTP needs AutoKEY for local 
> delivery only. The use of SNTP needs to be limited to local networks only 
> IMHO.
> 
> 
> Todd Glassey
> 
> ----- Original Message ----- 
> From: "Danny Mayer" <mayer at ntp.isc.org>
> To: "David L. Mills" <mills at udel.edu>
> Cc: <ntpwg at ntp.org>
> Sent: Sunday, June 01, 2008 6:32 AM
> Subject: Re: [ntpwg] KoD 'backoff' BCP/direction
> 
> 
>> Dave,
>>
>> No, they are not yours, they are mine. This is deliberate since your
>> reference implementation is just that. There are lots of other
>> implementations with NTP and especially SNTP and they need to know what
>> they need to do when they receive such a KOD packet.
>>
>> Danny
>>
>> David L. Mills wrote:
>>> Danny,
>>>
>>> These are not my words; I wish they would go away in a formal
>>> specification document. My recommendation, and I spent a good deal of
>>> time on it, is the headway scheme described in the current documentation
>>> and now implemented. This may not be the only scheme, but should serve
>>> as a model for future adaptations.
>>>
>>> Dave
>>>
>>> Danny Mayer wrote:
>>>
>>>> Harlan Stenn wrote:
>>>>
>>>>> The draft says:
>>>>>
>>>>> a. For kiss codes: DENY, RSTR the client MUST demobilize any
>>>>> associations to that server and stop sending packets to that
>>>>> server;
>>>>>
>>>>> b. For kiss code: RATE the client MUST immediately reduce its
>>>>> polling interval to that server and continue to reduce it each
>>>>> time it receives a RATE kiss code.
>>>>>
>>>>> >From my POV this is almost helpful.
>>>>>
>>>>> For case (a), for what duration SHOULD the client demobilize and stop
>>>>> sending packets to that server?
>>>>>
>>>> Indefinitely. It should never try and contact that server again.
>>>>
>>>>> For case (b), are there any recommendations on how much the client
>>>>> SHOULD reduce the rate at which it is polling the server?
>>>>>
>>>> No. It was deliberately left vague. It's hard to decide that question. I
>>>> would recommend backing off by doubling the interval between polls every
>>>> time one of these packets is received.
>>>>
>>>>> In case (b), do we mean 'polling rate' (or frequency) instead of
>>>>> 'polling interval'?
>>>>>
>>>> Yes, that's an error on my part. Thanks for catching it. It should be
>>>> reduced frequency.
>>>>
>>>>> Is there an easy way the server could 'offer a suggestion' in either of
>>>>> these cases? What are the costs/benefits to having the server offer
>>>>> ideas on these rate limits instead of relying solely on the client?
>>>> The server can never really make recommendations. That's up to the
>>>> implementation, dependent on requirements. Saying "back-off" should be
>>>> enough for the client to take the appropriate action.
>>>>
>>>> Danny
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg