Traffic shaping allows us to prioritize some traffic over other traffic, in order to optimize/improve network performance, and in some cases, lower latency. The purpose of traffic shaping is to make network traffic conform to certain predefined constraints, generally known as either a traffic profile or contract. The traffic shaper is able to do this because it examines packets; if the packets meet certain criteria, they are handled differently. In this sense, traffic shaping bears similarities to firewall rules. In the case of firewall rules, packets that meet rule criteria are either allowed, blocked, or rejected. In the case of traffic shaping, packets that meet certain criteria (we can call them traffic shaping rules) are put into different queues. These queues are implemented as FIFO buffers. Priority traffic is typically sent immediately, while lower-priority traffic is held until the higher-priority traffic has passed.
Traffic shaping has to be implemented where the router can control the flow of data. Therefore, in pfSense, traffic shaping is always applied when packets are leaving the router. For example, traffic shaping of incoming traffic to the LAN is actually applied when the traffic is leaving the LAN interface. Similarly, traffic shaping of outgoing traffic is applied when traffic is leaving the WAN interface.
Traffic shaping can be used for a variety of purposes. This includes the following:
- It can be used in a number of different scenarios where low latency is required. This includes VoIP traffic, which, if it is given the same priority as other traffic, may be affected by uploads and downloads. Similarly, if you are playing an online game, you want the response time to be as fast as possible, even if you are simultaneously downloading a file. Other applications can tolerate a higher level of latency. For example, with video streaming using online services, such as Netflix or Hulu, a certain amount of buffering is tolerable.
- It can be used to limit the amount of bandwidth used by peer-to-peer applications. It can do this in two different ways. One is by lowering the priority of traffic coming to and from well-known peer-to-peer ports. The second is by actually examining the packets and finding out what application is generating them. The latter is known as Layer 7 inspection, or Deep Packet Inspection. Both approaches have strengths and weaknesses. A port-based approach is easy to implement and will work in most cases, but users may be able to circumvent such an approach by using different ports. Layer 7 inspection is generally more effective in identifying peer-to-peer traffic, but it is also CPU-intensive, and it is of no help on encrypted traffic. In addition, small changes to the peer-to-peer protocol can result in Layer 7 inspection not working.
- It can be used to make asymmetric Internet connections work more smoothly. If your download bandwidth is significantly larger than your upload bandwidth, the maximum download speed may seem unattainable because you won't be able to send enough
ACKpackets back to the target host to keep the traffic flowing. This is most likely as the connection becomes more saturated; for example, if you are downloading a file while simultaneously loading a web page. In these situations, pfSense can prioritizeACKpackets, ensuring that traffic flows and that you are able to reach the maximum download speed. - In business environments, traffic shaping can be used to prioritize business-related traffic.
- ISPs have sometimes used traffic shaping to limit bandwidth consumption of certain programs (for example, BitTorrent traffic) so they can take on additional customers. This is often controversial, because such connections are often advertised as unlimited connections. Nonetheless, it is yet another example of traffic shaping being used for a specific outcome.
No discussion of traffic shaping would be complete without mentioning the different types of queues that can be utilized. The most basic queuing policy is a FIFO queue, sometimes also referred to as first-come, first-served (FCFS) queuing. With FIFO queuing, no packet is given priority; nor are there different classes of traffic. All packets are treated equally within the FIFO queue and packets are sent out in the order that they arrive.
Obviously, this makes for a very easy to implement policy. But when implemented, it can result in some users and applications consuming all the bandwidth. Even when they are not consuming bandwidth constantly, their usage may spike at inopportune times, delaying time-sensitive and important traffic. Worse yet, important traffic may be dropped because there is less important traffic in the queue.
Nonetheless, if you have congestion-free Internet connection on which users and applications have as much bandwidth as they need, FIFO queuing may be appropriate. It is easy to implement and also guarantees that your access to bandwidth is delay-free. If this is not the case, however, it is time to consider one of the many alternatives to FIFO queuing.
Fair queuing represented the first improvement over FIFO queuing. In it, each program process is given its own FIFO queue. This prevents a badly behaving process from monopolizing the bandwidth. A further refinement of fair queuing is weighted fair queuing (WFQ), which provides a form of priority management. Packets are ultimately classified into high-bandwidth traffic and low-bandwidth traffic, and low-bandwidth traffic is given priority over high-bandwidth traffic. In turn, high-bandwidth traffic shares the connection proportionally based on assigned weights. This ensures that low-bandwidth streams, which represent the bulk of network traffic, are transmitted in a timely manner. One of the drawbacks of WFQ is that it relies on examining the packets, so it does not work on encrypted connections.
There are three queuing disciplines supported by the current version of pfSense: priority queuing (PRIQ), class-based queuing (CBQ), and Hierarchical Fair Service Curve (HFSC). Each of these policies has advantages and disadvantages as we will soon see.
PRIQ is a queuing policy that divides traffic into different priority levels. Implementations differ in the number of levels, but in pfSense, there are seven levels, with seven being the highest priority. This is a flat hierarchy of priority levels. On each interface, priority queues are scanned for packets in descending order of priority. The highest priority queue is scanned first, then the next highest priority queue, and so forth. The packet at the head of the highest queue is chosen for sending. This procedure is repeated each time the traffic shaper chooses a packet to be sent.
A priority queue's behavior is defined by a set of rules that describe how packets should be assigned to priority queues. Packets can be classified by protocol or subprotocol type, which interface they come from, packet size, and so on. The advantage of PRIQ is that it is easy to configure and also easy to understand. It also ensures that absolute priority is given to traffic that is in the highest priority queue. The main disadvantage is that because priority always goes to higher-level traffic and there is no way of circumventing this policy or for moving traffic to a higher level once it has been assigned a lower level of priority, lower priority traffic can be completely starved of bandwidth. In addition, having only seven priority levels limits the granularity of traffic shaping; an interface which relies solely on priority queuing can have at most seven separate queues.
CBQ allows a bit more control than PRIQ. In CBQ, each class gets a percentage of bandwidth, after being grouped by classes. It divides traffic into a hierarchy of classes and thus allows you to classify traffic into a hierarchy. Criteria for prioritization can include protocol, the application being used, the IP address of the sender, and many other factors. It operates at the IP network layer (Layer 3). An additional appeal of CBQ is that it is in the public domain.
Each class is assigned a bandwidth limit, and packets within the class are processed until the bandwidth limit for the class is reached. This tends to ensure that even low-priority packets get some bandwidth. The first goal of CBQ is quantitative bandwidth sharing, but a secondary goal is that when some class is not using its allocated bandwidth, the distribution of excess bandwidth should not be arbitrary. Rather, the distribution of such bandwidth should follow a set of guidelines.
As an example of how PRIQ and CBQ differ, consider the case of the example network presented earlier. We want to assign the bulk of the bandwidth to the DEVELOPERS and ENGINEERING subnets. With priority level queuing, there is really no way of implementing such an arrangement. We could assign higher priority levels to DEVELOPERS and ENGINEERING than SALES and DMZ, with DEVELOPERS receiving a higher priority than ENGINEERING, but this could result in SALES and DMZ not receiving an adequate slice of bandwidth.
With CBQ, however, each subnet could be assigned a percentage of bandwidth. Even better, CBQ can be hierarchical, so that DEVELOPERS and ENGINEERING share a percentage of bandwidth, with ENGINEERING being assigned a greater portion of their shared bandwidth.
The third queuing discipline supported by pfSense is HFSC. An HFSC can be thought of as a form of bandwidth allocation in which guarantees are made about latency. An HFSC queue is defined by a nonlinear curve with two parts. The first part, m1, determines the amount of bandwidth the queue gets up to p milliseconds. After p milliseconds, the second part of the curve (m2) determines the behavior of the queue. This is the amount of bandwidth guaranteed to the queue.
To illustrate HFSC, imagine two services competing for bandwidth: a VoIP connection and a file download. Assume a linear service curve such that the VoIP connection requires that a packet be sent every 30 ms, while for the file download, a packet must be sent every 9 ms. Assume that it takes 7 ms to transmit a packet. If packets are sent according to these deadlines, the delay for a video packet will be approximately 21 ms. Such a policy ensures that the deadlines are met, but the latency for VoIP packets is high.
Now imagine a different service curve such that the VoIP connection gets the bulk of the bandwidth up until 10 ms (for example, 75% of available bandwidth). The inflection point is at 10 ms, and after that the VoIP connection only gets 25% of the available bandwidth. With this policy, the delay for any VoIP is no more than 10 ms. The result is a lower latency for VoIP traffic, but a higher latency for the file download traffic, but this is acceptable, since throughput is more important than latency with respect to file downloads.
The main drawbacks of HFSC is that unlike PRIQ and CBQ, which are defined by very simple criteria (priority levels in the case of priority queuing, and amount of bandwidth allocated to a class in the case of CBQ), HFSC queues are defined by nonlinear curves, and therefore are inherently more complex. There will be times when the traffic shaper cannot guarantee service to all curves at the same time, and/or it cannot do so fairly. Nonetheless, HFSC is a good choice for an algorithm if we are utilizing services that benefit from decoupling latency from bandwidth.