[ntpwg] KoD 'backoff' BCP/direction

[David L. Mills]

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
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg