> INTERNET > | > |eth0 202=2E14=2E41=2E1 > BW=2EManager > | | > | +----eth1----192=2E168=2E1=2E0/24 > | > +------eth2----192=2E168=2E2=2E0/24 > > Total incoming bandwidth to eth0 is 1024kbps > should be shared to eth1 and eth2, which mean each get 512Kbps and > burstable to 1024Kbps if other host is idle=2E
> This doesn't make sense to me. > The fact that an internal host is idle does not justify not sending > traffic TO it. > > The suggestions to use IMQ+HTB seem to miss the problem that > if someone sends 1024 to eth1 then nobody has a chance to even > begine to send anything to eth2.
Why not?
Ignore those bandwidth controller devices for a moment.
TCP flows compete to cope the available bandwidth. If your link capacity is 1024kbit and you start sending 1024kbit to the interface eth1 and sometime later (the time you want) begin to send 1024 kbit to interface eth2, you can be truly sure that when flows stabilize each of them will be try to cope 50% of the available bandwidth defined by the link capacity. Finally each flow will be 512kbit.
Now put on your controller devices. They can control the upper level of the flows but no the flows themselve. TCP is always testing the bandwidth availability trying to get more share from it. What stop this? When a packet is dropped the inner congestion control mechanism is fired and TCP reduce automatically its rate. Finally the fight converge to every flow sharing the upper level defined by the controller device, as soon as those flows have enough packets to reclaim it.
Conclusion: use your bandwidth controllers but never forget the TCP natural behavior.
Best regards,
Leonardo Balliache
