Subject: Re: [Dhcpv6bis] [dhcpv6bis] #119 (XML 3315): Client Rate limiting in DHCPv6?

From: Sheng Jiang <[email-masked]>
Date: Sun, 4 Jan 2015 05:52:30 +0000

I have changed the possible default rate limit to be 20 packets in 20 seconds. The shorter period means shorter effective time and shorter lockout time, particularly for looping situation. I hope this could be a good compromise.

Best regards,

Sheng

>-----Original Message-----
>From: dhcpv6bis issue tracker [mailto:[email-masked]]
>Sent: Wednesday, December 24, 2014 12:05 PM
>To: Sheng Jiang; [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [dhcpv6bis] #119 (XML 3315): Client Rate limiting in DHCPv6?
>
>#119: Client Rate limiting in DHCPv6?
>
>
>Comment (by [email-masked]):
>
> Ted did comment that he feels the default of 60 packets in 10 seconds is
> rather high (Sheng attributed that number to me - Bernie). It was a while
> ago and I'm not sure what number I suggested back then, but 60 in 60
> (i.e., 1/second on average, with short bursts possible) is probably much
> more realistic. We could also analyze various situations to derive a more
> meaningful number (sequences such as release, solicit, (advertise with
> server pref 255) request which can happen quickly - so a burst of 3
> packets in ~ 1 second is not unreasonable -- but of course this should not
> continue for long :).
>
>--
>-------------------------------------+-------------------------------------
> Reporter:                           |       Owner:
>[email-masked]
>  [email-masked]         |      Status:  closed
>     Type:  task                     |   Milestone:  B moderate,
>apply
> Priority:  P1 blocker               |  after merge
>Component:  XML 3315                 |  Resolution:  fixed
> Keywords:                           |    Due Date:
>-------------------------------------+-------------------------------------
>
>Ticket URL:
><http://trac.tools.ietf.org/group/dhcpv6bis/ticket/119#comment:6>
>dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Jan 2015 08:35:07 -0500

> I have changed the possible default rate limit to be 20 packets in 20 seconds. The shorter period means shorter effective time and shorter lockout time, particularly for looping situation. I hope t…

Thanks, Sheng.   Did you do the math on that?   I'm curious what the numbers looked like.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 4 Jan 2015 18:02:44 +0000

I think the math for normal transactions might argue for short bursts of more than 1 packet per second.

I'm not sure what Ted's math would be, but a typical sequence that could be expected might be a Release/Decline followed by Solicit (with 255 server pref) followed by a Request. All of these could occur within a second and, in a broken client case, be repeated (the client might also do a Decline and Release as Tim Winters indicated some clients are known to do). So it seems to me that short term bursts of a half dozen packets are acceptable (though unlikely). There might even be Information-Request mixed in if applications run that request options (assuming such a model is actually implemented in clients).

I also don't think we need something that triggers over the short term - it is more the long term sustained rate that is key to assure clients with bad logic/state flows don't exceed.

A true long term rate for client activity should be extremely low. Yet, allowing perhaps 4 packets quickly is also reasonable.

There are also cases where clients may "reboot" because something crashes the OS during the dhcp activity and if the dhcp activity can restart quickly, the client would not know what it did in recent past and hence no limiting is possible.

Then there's also the fast client handshake model the was presented to the working group a while back (IEEE work) which might need higher traffic levels if one is travel at high speec past lots of different access points? Though whether this model is realistic isn't clear; and what the time between changes would need to be?

I think I may be able to dig through some support email to determine values our customers have used with v4 for a "chatty client filter" we offer for our server - many SPs that use this must tune it for their environment, and when successfully tuned it often results in 50 to 70% of packets being dropped (mostly in cable environments) with no apparant negative subscriber impact. Here they configure a monitoring period and a packet limit, and once the client exceeds that rate, the server will drop packets until the client quiets down - which is another configurable time period and packet limit.

- Bernie
________________________________________
From: Ted Lemon [[email-masked]]
Sent: Sunday, January 04, 2015 8:35 AM
To: Sheng Jiang
Cc: Bernie Volz (volz); Tomek Mrugalski; [email-masked]
Subject: Re: [Dhcpv6bis] [dhcpv6bis] #119 (XML 3315): Client Rate limiting in DHCPv6?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Jan 2015 13:38:17 -0500

> Then there's also the fast client handshake model the was presented to the working group a while back (IEEE work) which might need higher traffic levels if one is travel at high speec past lots of…

I think a connection that would create a burst of messages so large that it would exceed the 20 packets in 20 seconds that Sheng is talking about would not support meaningful use of the network.   But one way to address this would be to say that the limit only applies to messages sent on a given link, and that for example if the SSID changes, then the packet count as it applies to this limit should be reset to zero.   Of course you could still get rapid switching between two SSIDs that might cause some server load if a lot of clients were doing it, but I don't think that's likely, and I don't think we need to address it.