(RADIATOR) rate limiting support for Radiator

[Bjoern A. Zeeb]

On Fri, 14 Jan 2005, Christian Kratzer wrote:

Hi,

> On Thu, 13 Jan 2005, Claudio Lapidus wrote:
>
> > Hello Christian
> >
> >> exactly what is it that you want to rate limit ? radius-requests ?
> >
> > There is a problem associated with very large access servers, typically in
> > ADSL environments. When, due to some problem in the network or in the box
> > itself, a lot (or all) of its users get disconnected at once, later, when
> > the original problem is solved you end up with thousands of users trying to
> > reconnect all at the same time, causing what is known as a "storm" of
> > Access-Requests. This poses a particular performance problem, especially
> > when the radius server in turn must proxy the requests to some other
> > servers, propagating the problem further into the network.
> >
> > The solution could be a mechanism built into the server process that, given
> > certain conditions, forwards to the proxy chain only a fraction of the
> > messages intended for it, in order to protect the remote server from the
> > traffic spike. The remaining requests could well be denied, forcing the end
> > user to try a reconnection some seconds later. This, at least in theory,
> > would achieve some effect of "shaping" the Radius traffic upstream in the
> > proxy chain.

Haven't seen this posting so replying to a response...

You won't get more than 256 Access-Requests a time from your NAS to
the same Radius server. The Identifier field is only one octet and
thus limits the maximum number of concurrent requests.

Also one radius to another (proxy radius setup) you won't have more
than 256 concurrent Access-Requests.

You can load balance this from your NAS to multiple radius servers
(if NAS supports this) to distribute load in your proxy radius setup.

But the overall problem will remain:
the access-requests your NAS sends out will hit some radius server.
If you want to have one server to sacrifice the pawn and then either
drop or delay the packets you might be able to keep the request storm
'away' from some backend but even more requests will be fired at the
radius server at the sharp end.

If you want to protect your backends from a storm you might be
able to simply drop every second packet if you have more than
n Access-Requests per time delta or even drop all new access requests
if there are more then n (n<256) Access-Requests in processing
(or even use more sophisticated maths;).

You could for sure easily achive this from within the PreProcessing
and PostAuth hooks.

_pseudo_-syntax only...

sub preprocessing_hook {
	if ($count>$limit) {
		drop;
	}
	++$count;
}

sub postauth_hook {
	--$count;
}

you might need to take care of synchronization of count depending
on the setup...

If dropping the NAS might re-send it after a timeout. So this
alone would help to spread requests over time and should be preferred
to sending Access-Rejects (else the NAS would be hammered with even
more dialing requests). Shaping might help further but depending on
delays in the and length of the proxy radius chain and request storm
you might also run into timeouts with the NAS on very high load and
get another Access-Request while processing the former...


just my 20cts.

-- 
Greetings
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.