[Olsr-users] Rate limiting in olsr networks

[David Murray]

Thanks for the replies, I will definitely try to rate limit each flow/IP 
address.

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

GW--------N1--------N2--------N3--------N4

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
Dave


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