[ntpwg] KoD 'backoff' BCP/direction

[TS Glassey]

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