[Olsr-users] Rate limiting in olsr networks
Fri Jul 4 03:44:28 CEST 2008
Thanks for the replies, I will definitely try to rate limit each flow/IP
Just to define the problem that I am talking about a little better. In
the example below, N1 and N4 are both simultaneously starting FTP
sessions to the gateway. Because the round trip time between the gateway
and node 1 is much smaller than node 4 its TCP window will grow much
faster than node 4 and (initially) it will get a much larger share of
For community networks it definitely seems that rate limiting at the
gateway is perhaps the best option. Thanks for the suggestions regarding
this, I think I have a bit of catchup reading to do with tbf, sfb and sfq :)
The other issue (which aaron pointed out the difficulty of) is with
regards to traffic affecting routing traffic. To me it seems similar to
the QoS situation on WAN links where you only allow data traffic to use
a maximum of 75% to 80% of the link. The rest is left for management
traffic and routing. As aaron pointed out:
>I would suggest that. But it is a non trivial task to find the actual
possible bandwidth in a wifi link.
>Let me give you an example:
>let's say that your link can actually transmitt at 18mbit netto
>so... you rate limit it to 16mbit. Want to keep some reserves, right?
>Then the next moment a big construction crane moves and blocks your
signal a bit. So the rate drops to 10mbit netto. But your tc settings
are still at 16mbit.
Initially I was thinking that you could have a program that monitored
the bit rate and adapted the tc settings to 20% under the bit rate but I
think that this problem is of a similar difficulty to the ETT problem.
Correct me if I am wrong but one of the most difficult parts of
implementing ETT is that neighbors are connected at different
transmission rates. Hence one neighbor may be associated at 54 Mbit and
another at 6 Mbit. In this case if we created tc settings for each
interface then we might rate limit the interface to 20 Mbit forgetting
that the 6 Mbit link could still be quickly saturated. I think that this
problem is the same as the ETT problem because it means that we need
different dynamic tc settings, per neighbor, not per interface.
Thank you for the replies and interesting discussion
Juliusz Chroboczek wrote:
>> So IMHO the rate limiting must follow somehow (any ideas out there?)
>> the actual netto transmittable rate.
> What I'm doing is simply to rate-limit the Internet gateways, and
> enforce per-source fairness on them. The most economic way to do that
> is sbf (which I mentioned in a previous message), but if you have
> a lot of memory and CPU, then other techniques exist, such as sfq and
> of course naïve fair queueing.
> The point is that fairness is not a goal in itself. The actual goal
> is to provide a satisfactory quality of service to all of your users,
> and assuming your network is not too badly congested, this can be done
> with just doing some moderate rate limiting at crucial points in the
> network, and only enforcing weak forms of fairness there.
> Our network is not usually congested, though, so I have little actual
> operational experience with that. Aaron, we definitely need to have
> another couple beers together.
More information about the Olsr-users