[ntpwg] KoD 'backoff' BCP/direction

[Brian Haberman]

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.

Regards,
Brian