Hi! As a lurker, I should probably introduce myself to all <waves>.
IMHO traffic control only works well if you need to shape/prioritise your outbound traffic. For regular use, prioritisation seems to work nicely. I thik you can achieve your objectives without manually cutting traffic shaping rules. You've probably read the (absence of) documentation on iproute/tc, or tried to, spent time rocking backwards and forwards under your desk, reread the (absence of) documentation, hid under the desk a while longer and then wished the weekend was here (I did). tc is good but it is a brittle solution. It takes a lot of tweaking to get working, and requires a whole lot of rejigging if you want to change your network parameters. As you are using squid, you can use the delay pools features to shape your http traffic. From the configuration guide (I referenced it at http://squid.visolve.com/squid/squid24s1/delaypool.htm#delay_pools) you'll note that "Objects retrieved from the cache will not be delayed.". End result, traffic shaping moves from tc to squid. Then, use the wonder shaper to prioritise your traffic. This makes low-latency traffic nice and snappy, and puts bulk traffic in the background where it belongs. The author has already done some of the hard work for you! You can find it at http://lartc.org/wondershaper/ This approach might meet your needs, depending on whether you are expecting to see a whole lot of other unwanted (eg P2P) traffic saturating your line out. Otherwise, you could use htb to provide rate limiting- see this http://people.redhat.com/harald/tc.html HTH, Seb On Wed, 14 Apr 2004 01:15 pm, Peter Rundle wrote: > Sluggers, > > Implementing a Linux gateway via DSL I'd like to do some traffic shaping > and have been googling up some info, some of which is conflicting and some > questions still remain un-answered so I thought I'd ask the collective > wisdom of Slug. > > I'd like to rate limit the bandwidth available for web surfing. The googled > wisdom on this appears to be that I can either; > > 1. limit the rate into the internet interface. > 2. limit the rate of return ACK packets from the internet interface > 3. limit the rate of packets leaving the linux gateways lan interface to > the desktop. > > Critics of approach 1. state that this is bad because it wastes bandwidth > as the packet has already been sent over the DSL and the only way to rate > limit is to drop packets which subsequently have to be retransmitted over > the DSL (sounds logical). > > Approach 2 seems like a neat idea but I haven't been able to grasp how it > would work as each ack packet reply is the same size but the packet(s) > being replied to could be significantly different in size, how do I > semi-accurately limit the rate? > > Approach 3 I assume works by slowing down the rate of data into the desktop > which in turn slows down the rate of ACK packets the desktop returns, and > hence the rate at which the web server delivers the subsequent packets > (corrections to this understanding gladly accepted). However, I intend to > run Squid as a transparent proxy server, and obviously I'd like to make > sure that traffic comming from the local box (squid cache) isn't subjected > to the bandwidth throtle. I know I can mark such packets with iptables and > I can assign them different priorities within the interfaces packet queue, > but how do I allow them a higher bandwidth (as opposed to priority) > > Ideas, comments, links flames etc appreciated > > TIA's > > P. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
