[ntpwg] KoD 'backoff' BCP/direction

[Danny Mayer]

Dave,

That's my opinion too.

Danny

David L. Mills wrote:
> Danny,
> 
> I spent a good deal of time on KoD/backoff schemes in the recent 
> version. There is in fact an opportunity to use the received ppoll 
> variable under certain circumstances to clamp the transmit poll 
> interval, but it is part of the headway scheme and quite intricate. I 
> suspect few people will figure out how it works and probably nobody else 
> will implement it. I advise leaving the text as is. Leaving some things 
> for future refinement is in the best spirit of Internet technology.
> 
> Dave
> 
> Danny Mayer wrote:
> 
>> 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