Traffic Shaping


Traffic shaping is the system by which traffic is constrained to a specific speed. Its use applies to rationing internet access for certain users, as well as reducing the load certain types of traffic can create (e.g. email can be given a slow traffic lane to allow fast responses for web traffic).

The basic principle of traffic shaping is based on the fact that the outgoing traffic from the FireBrick is scheduled. Each packet has a time stamp stating when it is to be sent, and all traffic is (normally) sent in order, and not before its time. This method is used to deliberately slow responses from reject and bounce filters, as well as for speed lanes.

The objective is to emulate a router connected to a slow link.

One key advantage is that by limiting the speed of traffic leaving the FireBrick to a real router, you can ensure that the queuing of traffic is always in the FireBrick where you have more control (such as queue jumping outgoing TCP ACK messages, or making some traffic slower than others).

Speed Lanes

The FireBrick maintains a number of speed lanes. Each is given a name, and a speed to the WAN and a speed to the LAN. Speed limiting only applies to traffic which is to the LAN or the WAN (i.e. traffic that is going to a tunnel is not shaped in that direction but the final tunnelled data may be).

Internally, the FireBrick keeps track of how long it would have taken for the packets to be sent at the required speed. This means that it knows when the next packet could start sending based on what has already been sent. If that time is passed when a packet is to be sent, it is caught up with now.

When sending a packet, its length is considered, and that transmission time added to time for the next packet to be sent.

This ensures packets can only actually leave at the designated rate, and no faster. Note that the speed lane stats collect data as packets go in to the queue and not when they are actually sent, and so can show a higher rate.

Bandwidth sharing

A speed limit has two additional options - give and take. Each direction of each speed lane may give unused bandwidth away, and each lane may be set to take unused bandwidth. This is calculated every second, adding up all of the given away bandwidth and allocating to all lanes which will take such bandwidth. This does mean that a lane that gives bandwidth may receive it back if it takes bandwidth - but this means that the lanes maintain a relative priority. In addition, a cap can be set on the bandwidth a lane can take.

When bonus bandwidth is allocated to a lane, increasing its allocation, this is added gradually over several seconds. When decreasing the bonus, this happens immediately.

Shaping rules

A list of rules, like the filtering rules, are used to decide what speed lane each session is placed in. This is based on the initial packet that creates the session and applies independently of any filtering rules.

The first matching rule is applied. All traffic in a session is then sent via that speed lane.

The rules include :-

  1. Source interface
  2. Target interface
  3. Source IP
  4. Target IP
  5. Source Ports (for UDP/TCP)
  6. Target Ports (for UDP/TCP)
In addition, the shaping rule has a both ways option which checks for traffic in the other direction. Note that this checks for traffic from the target IP and to the source IP, but still checks that it is from the source port and to the target port. This is because it is more common to need to trap, say, all SMTP traffic either way between two points that it is to try and trap traffic to SMTP or from SMTP, the later being meaningless in most contexts. If you require the former, create two separate rules.

Buffer overflow

The outgoing queues are limited in size, and also a packet will not be sent if it is too far in the future. This limits the traffic that can be carried.

Also, new packets with earlier times to send can also push out old traffic if the queue is full. This can mean packets are silently dropped (and this is not reflected on the statistics or the speed lane control).

Changing rules

Unlike filtering and routing rules, it is desirable to ensure that traffic shaping rules can be changed on the fly, even for established sessions. This is particularly important where profiles (e.g. based on time of day) are used to change shaping rules. It would not be helpful to restrict web traffic after 9am, if a large download started at 8:59am could continue unrestricted. As such the shaping rules are constantly re-evaluated as a background task, updating the sessions to new speed lanes if appropriate.

Also, speed lane speeds can be changed at any time will immediate effect. however it should be noted that TCP may take several seconds to react to large changes.

Fast ACKs

The speed lane settings include a FastACK check box. This turns on a queue jumping feature which causes TCP packets with no payload (typically ACKs) to queue jump the normal speed lane. The time taken for the packet is still allowed when considering the timing of the next packet.

This feature can be used when limiting outgoing traffic on an ADSL line, so that the incoming traffic is not slowed by delayed ACK packets going through the outgoing speed lane.

Master speed lane

The first speed lane is the master speed lane and is applied to traffic even after it has gone through a specific speed lane. This allows the overall traffic rates to be controlled, and is invaluable if you are trying to ensure that an external router never fills its buffers. It is useful when used in conjuntion with the FastACK feature allowing the firebrick to control the order of some traffic. Note that setting FastACK on the master means it applies to all lanes. The Fast option on speed lanes allows traffic on that lane to not have the master speed lane applied. The traffic still affects the overall speed of the master speed lane, but Fast lane pakets effectively queue jump the normal traffic.