[ntpwg] KoD 'backoff' BCP/direction

[TS Glassey]

Brian (please don't take these acerbic words personally - there are many 
wizards here...)

----- Original Message ----- 
From: "Brian Haberman" <brian at innovationslab.net>
To: "TS Glassey" <tglassey at certichron.com>
Cc: <mayer at ntp.isc.org>; "David L. Mills" <mills at udel.edu>; <ntpwg at ntp.org>
Sent: Sunday, June 01, 2008 10:10 AM
Subject: Re: [ntpwg] KoD 'backoff' BCP/direction


> 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.

Then the Charter is broken - since NTP4 is with these extensuions trying to 
be all things to all people, and it cannot be by NTP's very design.

> 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.

TICTOC (the IETF's new Precision Time WG is even more clueless IMHO).

>
> 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
>