At 02:38 29/04/2004 +0200, Adam wrote:
>Hi Didier,
>
>OK, fair enough, so it does make sense to do inbound bandwidth managment 
>IF you have several users on the same WAN line. I was assuming one / a few 
>users, since this seemed to be the situation of the original poster (any 
>myself as well!)
>
>Am I correct in assuming that it is still not very efficient to limit 
>inbound bandwidth in a case where only a single or a few PCs are using the 
>WAN line, and you want to limit one kind of traffic in relation to another 
>(such as keeping HTTP/IMAP/VoIP responsive in preference over P2P/FTP/... 
>and such) rather than simply ensuring "fair" sharing of the WAN line?

It's another kind of problem, but the logic is similar. In your case, it's 
a question of sharing unevenly between several kinds of ports instead of 
sharing evenly between several IP addresses. Here's a variant for this 
specific problem:

"""
pipe_up_size="24Kbytes" # adapt to your link
pipe_down_size="96Kbytes" # ...
queue_up_size="24Kbytes" # same as pipe
queue_down_size="96Kbytes" # same as pipe
ports_high_weight="1-1000,2401,3306,8000,8080" # adapt to your taste
up_high_weight=10 # adapt to your taste
up_low_weight=1 # ...
down_high_weight=10 # ...
down_low_weight=1 # ...

${fwcmd} add pipe 1 all from ${iip} to any out xmit ${oif}
${fwcmd} add pipe 2 all from any to ${iip} in recv ${oif}
${fwcmd} pipe 1 config queue ${pipe_up_size}
${fwcmd} pipe 2 config queue ${pipe_down_size}

${fwcmd} add queue 1 all from ${iip} to any ${ports_high_weight} out xmit 
${oif}
${fwcmd} add queue 2 all from any ${ports_high_weight} to ${iip} in recv ${oif}
${fwcmd} add queue 3 all from ${iip} to any not ${ports_high_weight} out 
xmit ${oif}
${fwcmd} add queue 4 all from any not ${ports_high_weight} to ${iip} in 
recv ${oif}

${fwcmd} queue 1 config pipe 1 weight ${up_high_weight} queue ${queue_up_size}
${fwcmd} queue 2 config pipe 2 weight ${down_high_weight} queue 
${queue_down_size}
${fwcmd} queue 3 config pipe 1 weight ${up_low_weight} queue ${queue_up_size}
${fwcmd} queue 4 config pipe 2 weight ${down_low_weight} queue 
${queue_down_size}
"""

With such a config, higher priority ports would be served faster than lower 
priority ones, whenever they are competing for bandwidth use (10 times 
faster in the example case). The important thing to understand is how to 
shape the traffic by just delaying the ACKs and the relation between the 
queue size and the TCP window size.



>I'm not sure I follow your (rather complex) DummyNet configuration 
>examples, but in case I can wrap my mind around these, am I correct in 
>assuming some of this can't currently be done from the m0n0wall traffic 
>shaper GUI? (That is, without using exec.php cmds.)

I haven't hacked m0n0wall GUI enough to tell precisely, since I am not a 
m0n0wall user, but an admirer using it as a source of inspiration. For 
practical use, I prefer to have a fully featured FreeBSD system and deal 
directly with the raw configuration files rather than via some GUI.

As far as I know, I don't see any fundamental reason why it couldn't be 
done with m0n0wall since you don't rely on IP adresses before NAT. What I 
don't know is how easy/difficult it is to implement it using the GUI.

PS: there was a typo in my previous mail, making it rather confusing:
"""
...
${fwcmd} pipe 1 config queue ${pipe_up_size}
${fwcmd} pipe 2 config queue ${pipe_down_size}
"""           ^

Didier

--
Didier Lebrun
Le bourg - 81140 - Vaour (France)
tél: 05.63.53.73.41
mailto:dl at vaour dot net (MIME, ISO latin 1)
http://didier.quartier-rural.org/