[ntpwg] KoD 'backoff' BCP/direction

[David L. Mills]

Brian,

The current rate controls described in the documentation and 
implementation have three parameters, the minium headway, average 
headway and burst tolerance. This is effective for transmitted packets 
and monitored for receive packets. This is also how the KoD packets are 
generated and how they are responded. I'm not sure this is the only way 
to manage rate controls, but it certainly works well and could be a 
model for other adaptations. Before specifying in concrete, at least 
folks should understand the documented model. Frankly, I think this 
should not be in the specifcation, but in a best practices manual.

Dave

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