[ntpwg] KoD 'backoff' BCP/direction

[Danny Mayer]

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