[ previous ] [ next ] [ threads ]
 
 From:  Adam Nellemann <adam at nellemann dot nu>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] bandwidth limiting
 Date:  Tue, 11 May 2004 20:33:37 +0200
Hi David (and others),

I'm glad to hear (from whoever it was posted this info) that inbound 
shaping will work (I'll certainly try to put my inbound 
rules/pipes/queues again at the next opportune moment...)

Regarding how to do dynamic shaping:

You can achieve something along those lines, but due to the underlying 
technology of m0n0walls shaper (dymmynet), this is done in a somewhat 
counter-intuitive way, and lack the level of "control" one would like 
to have over such things.

Here's how you do it:

(For clarity I'll only discuss one set of pipes, queues and rules, but 
it is basically a matter of doing the same for the other direction 
with its own set of pipes, queues and rules.)

Instead of masking the pipe (which you do to get a static bandwidth 
sharing), you simply mask the queue(s). Since the pipe isn't masked, 
there will only be one of these, and it will be shared between all the 
users, so you need to set the pipe bandwidth to the total bandwidth 
used (= users x bandwidth_per_user). Since the queues are masked, each 
user will get his own queue, and the shaper will devide the pipe 
bandwidth equally between these (equally since each "virtual queue" 
will have the same weight).

If you want some users having a higher (or lower) priority, or perhaps 
some traffic, you simply make another masked queue with a higher 
(lower) weight, and some rules to put the high (low) priority traffic 
through that instead.

The problem with the dummynet implementation is that it only provides 
this "wight" system for prioritising traffic. First of all I've not 
had great succes with these weights (but I've only tried it for 
prioritising different types of traffic, might work better with 
different users/hosts?) Second, it doesn't allow you to prioritise (in 
the strict sense) the traffic (that is, even a queue with low weight 
will still get its share of the bandwidth, even if queues with higher 
weight are backlogged!) And third, it is not that easy to control 
exactly which users get how much and when etc.

All this being said, I think that masked queues might be quite good 
for sharing bandwidth between a number of hosts (users), especially if 
you make sure to set the bandwidth of the pipe to a little less than 
you actual (measured) max. WAN bandwidth.

Hope this helps.

Adam.


David Rodgers wrote:

> I am not sure about doing this within m0n0 
> In theory at least you could define queues to accomplish the sharing effect 
> that you desire.
> 
> There also is a project I have seen 
> pop up in a few places that does exactly what you are talking about I think.
> 
> It's call the "Bandwidth Arbitrator"
> http://freshmeat.net/projects/arbitrator/
> 
> David
> 
> On Tuesday 11 May 2004 11:43, Jose Iadicicco wrote:
> 
>>Adam and you all friends:
>>                          The incoming traffic shaping works perfect!!! I
>>did it works since the version 21 beta of Monowall ant it solves my problem
>>(i have a net with 12 users that share an ADSL connecion 512 kbits
>>downdstream and 128 kbits upstream and when one user opens a program like
>>Kazaa it takes all the bandwidth and the others users cant navegate). I
>>solve this making pipes of 64 kbits downstream and 32 kbits upstream, it is

>>would be some way of dinamic sharing of the bandwidth.
>>I read a lot of info but i dont know how can I do it!
>>
>>Can anyone help me and helps a lot of guys like me that has the same
>>problem?
>>
>>Jose
>>
>>

>>
>>
>>>Dinesh Nair wrote:
>>>
>>>>On Mon, 10 May 2004, Tony Pitman wrote:
>>>>
>>>>>Well, it is the incoming traffic that is going to be the big problem. I
>>>>>need to be able to limit how much bandwidth someone can use for
>>>>>downloading and web browsing. Please expand (without rehashing too much
>>>>>as you indicated) on what you mean.
>>>>
>>>>incoming traffic reaches your m0n0wall before it can be shaped. if it's
>>>>reached your m0n0wall, it's already put a load on your incoming T1,
>>>>thus serving no useful purpose in reality.
>>>
>>>While this is true, some time ago there were some posts to the
>>>contrary (by someone apparantly with a great deal of knowledge about
>>>these things). It would appear that inbound shaping can have some
>>>effect, due to packets being dropped, which will apparantly cause most
>>>servers to slow down transmission of new packets or something along
>>>those lines?
>>>
>>>
>>>>however, since you have dual interfaces, you can set outbound traffic
>>>>shaping on your wan link and outbound shaping on your lan link. the
>>>>outbound on your lan should be equivalent to the inbound on your wan,
>>>>and under your control.
>>>
>>>While I'm not sure, I should think it would have (nearly) the same
>>>effect if the inbound shaping is done on the WAN interface, at least
>>>if a queue is used, as m0n0wall should then accept the packages and
>>>hold them in it's own queue, rather than simply dropping them. But as
>>>mentioned, it would appear that sometimes it is preferable that
>>>packets are dropped, so..?
>>>
>>>= = =
>>>
>>>I guess the issue here is to provide a static "cap" on the inbound
>>>bandwidth of 128K, so a given user only gets what has been paid for.
>>>The issue of optimal WAN line usage shouldn't be that important (after
>>>all it is a T1 line!) and as mentioned there is a good chance that it
>>>will actually result in rather good line usage even so.
>>>
>>>I would certainly try shaping both directions (possibly experimenting
>>>a bit to see if inbound should be done on the WAN or the LAN IF), only
>>>if this seem to cause some kind of problem would I consider removing
>>>the inbound shaping (in which case I'd try to do some clever outbound
>>>ACK shaping and such instead).
>>>
>>>
>>>Regards,
>>>
>>>Adam.
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>>>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>>
>>=====
>>El objetivo escencial del correr es probar los limites de la voluntad
>>humana...
>>
>>------------



>>http://autos.yahoo.com.ar
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>