ADSL Bandwidth Management HOWTO - Dan Singletary (best romantic novels to read .txt) 📗

|

| This script was originally based on the ADSL WonderShaper as seen at the |

| [http://www.lartc.org] LARTC website. |

| |

+---------------------------------------------------------------------------+

!/bin/bash myshaper - DSL/Cable modem outbound traffic shaper and prioritizer. Based on the ADSL/Cable wondershaper (www.lartc.org) Written by Dan Singletary (8/7/02) NOTE!! - This script assumes your kernel has been patched with the appropriate HTB queue and IMQ patches available here: (subnote: future kernels may not require patching) http://luxik.cdi.cz/~devik/qos/htb/ http://luxik.cdi.cz/~patrick/imq/ Configuration options for myshaper: DEV - set to ethX that connects to DSL/Cable Modem RATEUP - set this to slightly lower than your outbound bandwidth on the DSL/Cable Modem. I have a 1500/128 DSL line and setting RATEUP=90 works well for my 128kbps upstream. However, your mileage may vary. RATEDN - set this to slightly lower than your inbound bandwidth on the DSL/Cable Modem. Theory on using imq to "shape" inbound traffic: It's impossible to directly limit the rate of data that will be sent to you by other hosts on the internet. In order to shape the inbound traffic rate, we have to rely on the congestion avoidance algorithms in TCP. Because of this, WE CAN ONLY ATTEMPT TO SHAPE INBOUND TRAFFIC ON TCP CONNECTIONS. This means that any traffic that is not tcp should be placed in the high-prio class, since dropping a non-tcp packet will most likely result in a retransmit which will do nothing but unnecessarily consume bandwidth. We attempt to shape inbound TCP traffic by dropping tcp packets when they overflow the HTB queue which will only pass them on at a certain rate (RATEDN) which is slightly lower than the actual capability of the inbound device. By dropping TCP packets that are over-rate, we are simulating the same packets getting dropped due to a queue-overflow on our ISP's side. The advantage of this is that our ISP's queue will never fill because TCP will slow it's transmission rate in response to the dropped packets in the assumption that it has filled the ISP's queue, when in reality it has not. The advantage of using a priority-based queuing discipline is that we can specifically choose NOT to drop certain types of packets that we place in the higher priority buckets (ssh, telnet, etc). This is because packets will always be dequeued from the lowest priority class with the stipulation that packets will still be dequeued from every class fairly at a minimum rate (in this script, each bucket will deliver at least it's fair share of 1/7 of the bandwidth). Reiterating main points: * Dropping a tcp packet on a connection will lead to a slower rate of reception for that connection due to the congestion avoidance algorithm. * We gain nothing from dropping non-TCP packets. In fact, if they were important they would probably be retransmitted anyways so we want to try to never drop these packets. This means that saturated TCP connections will not negatively effect protocols that don't have a built-in retransmit like TCP. * Slowing down incoming TCP connections such that the total inbound rate is less than the true capability of the device (ADSL/Cable Modem) SHOULD result in little to no packets being queued on the ISP's side (DSLAM, cable concentrator, etc). Since these ISP queues have been observed to queue 4 seconds of data at 1500Kbps or 6 megabits of data, having no packets queued there will mean lower latency. Caveats (questions posed before testing): * Will limiting inbound traffic in this fashion result in poor bulk TCP performance? - Preliminary answer is no! Seems that by prioritizing ACK packets (small <64b) we maximize throughput by not wasting bandwidth on retransmitted packets that we already have. NOTE: The following configuration works well for my setup: 1.5M/128K ADSL via Pacific Bell Internet (SBC Global Services)

DEV=eth0

RATEUP=90

RATEDN=700 # Note that this is significantly lower than the capacity of 1500.

# Because of this, you may not want to bother limiting inbound traffic # until a better implementation such as TCP window manipulation can be used. End Configuration Options

if [ "$1" = "status" ]

then

echo "[qdisc]" tc -s qdisc show dev $DEV tc -s qdisc show dev imq0 echo "[class]" tc -s class show dev $DEV tc -s class show dev imq0 echo "[filter]" tc -s filter show dev $DEV tc -s filter show dev imq0 echo "[iptables]" iptables -t mangle -L MYSHAPER-OUT -v -x 2> /dev/null iptables -t mangle -L MYSHAPER-IN -v -x 2> /dev/null exit

fi

Reset everything to a known state (cleared)

tc qdisc del dev $DEV root 2> /dev/null > /dev/null

tc qdisc del dev imq0 root 2> /dev/null > /dev/null

iptables -t mangle -D POSTROUTING -o $DEV -j