Subject: Re: [ntpwg] KoD 'backoff' BCP/direction

From: "Greg Dowd" <[email-masked]>
Date: Wed, 28 May 2008 16:10:59 -0700

The server reply has poll field.  It could suggest a maximum poll rate?

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"Everything should be made as simple as possible, but no simpler" Albert
Einstein

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
Harlan Stenn
Sent: Wednesday, May 28, 2008 4:00 PM
To: [email-masked]
Subject: [ntpwg] KoD 'backoff' BCP/direction

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?

For case (b), are there any recommendations on how much the client
SHOULD reduce the rate at which it is polling the server?

In case (b), do we mean 'polling rate' (or frequency) instead of
'polling interval'?

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?

--
Harlan Stenn <[email-masked]>
http://ntpforum.isc.org  - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 May 2008 22:59:52 +0000

The draft says:

---

From: Danny Mayer <[email-masked]>
Date: Wed, 28 May 2008 23:38:51 -0400

> sending packets to that server?

Indefinitely. It should never try and contact that server again.

> 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.

> In case (b), do we mean 'polling rate' (or frequency) instead of

Yes, that's an error on my part. Thanks for catching it. It should be 
reduced frequency.

> 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.

Danny

---

From: Brian Haberman <[email-masked]>
Date: Thu, 29 May 2008 09:58:40 -0400

> Indefinitely. It should never try and contact that server again.

That is my understanding as well.

> time one of these packets is received.

Exponential backoff works well.

> 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

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 30 May 2008 14:39:04 +0000

Danny,

These are not my words; I wish they would go away in a formal 
specification document. My recommendation, and I spent a good deal of 
time on it, is the headway scheme described in the current documentation 
and now implemented. This may not be the only scheme, but should serve 
as a model for future adaptations.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 30 May 2008 14:45:45 +0000

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

---

From: Danny Mayer <[email-masked]>
Date: Sat, 31 May 2008 21:52:00 -0400

Brian Haberman wrote:
>> 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.
>>
> 

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