[ntpwg] KoD 'backoff' BCP/direction

Danny Mayer mayer at ntp.isc.org
Sun Jun 1 01:52:00 UTC 2008


Brian Haberman wrote:
> 
> 
> 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.
> 
> That is my understanding as well.
> 
>>
>>> 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.
>>
> 
> Exponential backoff works well.
> 
>>> 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.
> 
> Why can't the server make a recommendation?  In the multicast group 
> management protocols a Query message specifies a delay value that 
> controls the burstiness of the responses sent back.  The poll field 
> could be used in the same manner.
> 

It could, but only if it can decide such a value. I'm not clear how it 
could make such a decision since each server will have different 
characteristics. I don't think we can make the poll field contain any 
particular value but I'm open to suggestions on how to implement this.

Danny



More information about the ntpwg mailing list