ADSL Bandwidth Management HOWTO by Dan Singletary (inspirational books for students TXT) π
-----
3.5. Attempting to Throttle Inbound Traffic
By using the Intermediate Queuing Device (IMQ), we can run all incoming packets through a queue in the same way that we queue outbound packets. Packet priority is much simpler in this case. Since we can only (attempt to) control inbound TCP traffic, we'll put all non-TCP traffic in the 0x00 class, and all TCP traffic in the 0x01 class. We'll also place "small" TCP packets in the 0x00 class since these are most likely ACK packets for outbound data that has already been sent. We'll set up a standard FIFO queue on the 0x00 class, and we'll set up a Random Early Drop (RED) queue on the 0x01 class. RED is better than a FIFO (tail-drop) queue at controlling TCP because it will drop packets before the queue overflows in an attempt to slow down transfers that look like they're about to get out of control. We'll also rate-limit bot
Read free book Β«ADSL Bandwidth Management HOWTO by Dan Singletary (inspirational books for students TXT) πΒ» - read online or download for free at americanlibrarybooks.com
- Author: Dan Singletary
- Performer: -
Read book online Β«ADSL Bandwidth Management HOWTO by Dan Singletary (inspirational books for students TXT) πΒ». Author - Dan Singletary
| ----------------- |
| | .. | eth1..ethN |
| | | |
| V V |
| |
| Local Network |
| |
+----------------------------------------------------------------------------+
2.3. Packet Queues
Packet queues are buckets that hold data for a network device when it can't
be immediately sent. Most packet queues use a FIFO (first in, first out)
discipline unless they've been specially configured to do otherwise. What
this means is that when the packet queue for a device is completely full, the
packet most recently placed in the queue will be sent over the device only
after all the other packets in the queue at that time have been sent.
2.3.1. The Upstream
With an ADSL modem, bandwidth is asymmetric with 1.5Mbit/s typical downstream
and 128kbit/sec typical upstream. Although this is the line speed, the
interface between the Linux Router PC and the ADSL modem is typically at or
above 10Mbit/s. If the interface to the Local Network is also 10Mbit/s, there
will typically be NO QUEUING at the router when packets are sent from the
Local Network to the Internet. Packets are sent out eth0 as fast as they are
received from the Local Network. Instead, packets are queued at the ADSL
modem since they are arriving at 10Mbit/s and only being sent at 128kbit/s.
Eventually the packet queue at the ADSL modem will become full and any more
packets sent to it will be silently dropped. TCP is designed to handle this
and will adjust it's transmit window size accordingly to take full advantage
of the available bandwidth.
While packet queues combined with TCP result in the most effective use of
bandwidth, large FIFO queues can increase the latency for interactive
traffic.
Another type of queue that is somewhat like FIFO is an n-band priority queue.
However, instead of having just one queue that packets line up in, the n-band
priority queue has n FIFO queues which packets are placed in by their
classification. Each queue has a priority and packets are always dequeued
from the highest priority queue that contains packets. Using this discipline
FTP packets can be placed in a lower priority queue than telnet packets so
that even during an FTP upload, a single telnet packet will jump the queue
and be sent immediately.
This document has been revised to use a new queue in linux called the
Hierarchical Token Bucket (HTB). The HTB queue is much like the n-band queue
described above, but it has the capability to limit the rate of traffic in
each class. In addition to this, it has the ability to set up classes of
traffic beneath other classes creating a hierarchy of classes. Fully
describing HTB is beyond the scope of this document, but more information can
be found at [http://www.lartc.org] http://www.lartc.org
2.3.2. The Downstream
Traffic coming inbound on your ADSL modem is queued in much the same way as
outbound traffic, however the queue resides at your ISP. Because of this, you
probably don't have direct control of how packets are queued or which types
of traffic get preferential treatment. The only way to keep your latency low
here is to make sure that people don't send you data too fast. Unfortunately,
there's no way to directly control the speed at which packets arrive, but
since a majority of your traffic is most likely TCP, there are some ways to
slow down the senders:
οΏ½οΏ½*οΏ½Intentionally drop inbound packets - TCP is designed to take full
advantage of the available bandwidth while also avoiding congestion of the link. This means that during a bulk data transfer TCP will send more and more data until eventually a packet is dropped. TCP detects this and reduces it's transmission window. This cycle continues throughout the transfer and assures data is moved as quickly as possible.οΏ½οΏ½*οΏ½Manipulate the advertised receive window - During a TCP transfer, the
receiver sends back a continuous stream of acknowledgment (ACK) packets. Included in the ACK packets is a window size advertisement which states the maximum amount of unacknowledged data the receiver should send. By manipulating the window size of outbound ACK packets we can intentionally slow down the sender. At the moment there is no (free) implementation for this type of flow-control on Linux (however I may be working on one!). How it WorksThere are two basic steps to optimize upstream bandwidth. First we have to
find a way to prevent the ADSL modem from queuing packets since we have no
control over how it handles the queue. In order to do this we will throttle
the amount of data the router sends out eth0 to be slightly less than the
total upstream bandwidth of the ADSL modem. This will result in the router
having to queue packets that arrive from the Local Network faster than it is
allowed to send them.
The second step is to set up priority queuing discipline on the router. We'll
investigate a queue that can be configured to give priority to interactive
traffic such as telnet and multi-player games.
+---------------------------------------------------------------------------+
| |
| By using the HTB queue we can accomplish bandwidth shaping and priority |
| queuing at the same time while also assuring that no priority class is |
| starved by another. Avoiding starvation wasn't possible using the method |
| outlined in the 0.1 revision of this document. |
| |
+---------------------------------------------------------------------------+
The final step is to configure the firewall to prioritize packets by using
fwmark.
3.1. Throttling Outbound Traffic with Linux HTB
Although the connection between the router and the modem is at 10Mbit/s, the
modem is only able to send data at 128kbit/s. Any data sent in excess of that
rate will be queued at the modem. Thus, a ping packet sent from the router
may go to the modem immediately, but may take a few seconds to actually get
sent out to the Internet if the queue in the modem has any packets in it.
Unfortunately most ADSL modems provide no mechanism to specify how packets
are dequeued or how large the queue is, so our first objective is to move the
place where the outbound packets are queued to somewhere where we have more
control over the queue.
We'll do this by using the HTB queue to limit the rate at which we send
packets to the ADSL modem. Even though our upstream bandwidth may be 128kbit/
s we'll have to limit the rate at which we send packets to be slightly below
that. If we want to lower the latency we have to be SURE that not a single
packet is ever queued at the modem. Through experimentation I have found that
limiting the outbound traffic to about 90kbit/s gives me almost 95% of the
bandwidth I could achieve without HTB rate control. With HTB enabled at this
rate, we've prevented the ADSL modem from queuing packets.
3.2. Priority Queuing with HTB
+---------------------------------------------------------------------------+
| |
| Note: previous claims in this section (originally named N-band priority |
| queuing) were later found to be incorrect. It actually WAS possible to |
| classify packets into the individual bands of the priority queue by only |
| using the fwmark field, however it was poorly documented at the writing |
| of version 0.1 of this document
Comments (0)