Quality of Service - Part 2: A Taxonomy of Traffic Management Policies
Posted 8 September 2011 | 
| 
0 Comments
Within the IT industry it has become customary to use the term quality-of-service to mean the management of traffic rather than the some measure of the service level. This has merely become the adopted convention. In this article I drop the established convention “quality-of-service” term in favour of traffic management. Traffic management is applied at the router/switch attempts to optimise network resources. In this article, we identify four categories of traffic management policy which we will examine in turn:
- Forwarding policy
- Scheduling policy
- Drop policy
- Work conserving policy
Forwarding Policy: The forwarding policy determines how packets are routed through the network. As a packet arrives on an ingress interface, the router (or switch) must decide on which egress interface to transmit the packet onto its destination. The most common forwarding policy is least-cost to destination. The router consults its routing tables and finds the network for the packet’s destination address. The routing table will specify the interface which is on the shortest-path to the network of the destination. The “shortest-path” is the route through the network with the lowest routing metric, i.e., the least-cost. What constitutes the least-cost depends on the routing protocol. For example, RIP [2] uses the number of hops as a routing metric, whereas OSPF [4] uses a cost metric based upon the speed of the link.
Least-cost routing algorithms can cause traffic hotspots - this is where links on the shortest-path can become congested, while other links are underutilised. Manual adjustments of the routing metrics can be employed to load balance traffic. However, speaking from (bitter) experience, this is not an ideal solution as it can lead to stability problems. Policy routing can be used to route packets along specific paths. With policy routing, packets are not forwarded based on destination address alone - source addresses and port numbers can be used to determine the next hop.
Policy routing does have scalability issues as it is difficult to keep track of the policies in use. Furthermore, the packet processing overhead can be high. One way around these issues is Multi-protocol Label Switching (MPLS) [1], which provides a management infrastructure for directing flows along pre-defined paths in the network.
Some wireless mesh routing protocols are not based on least-cost link metrics. Sensor networks, that often rely on battery power, need to avoid hotspots because nodes on popular shortest-paths may rapidly deplete their battery energy. This could cause sections of the mesh network to become disconnected. For this reason, mesh routing protocols seek to distribute energy consumption evening throughout the network.
Scheduling Policy: Scheduling policies determine the order that packets are transmitted. The most common is first-come-first-served (FIFO). This method uses a single queue, arriving packets are added to the end of the queue. Packets are taken from the front of the queue and transmitted when the communication facility becomes available. FIFO, while net neutral, can lead to unfairness as it treats the packets in each flow equally. Badly behaving flows will, therefore, get a greater portion of the networking resources at the expense of well-behaved flows.
Instead of using a single queue (per interface), multiple queues can be used to isolate flows and mitigate the effect of those that are badly behaved.
Priority queuing differentiates between flows and serves high-priority flows in preference to lower priority flows. Multiple queues are used and each is assigned a priority. Each queue (starting at the highest) is serviced in descending priority order. The next queue is not serviced until the current queue has been depleted. During congestion periods, priority queuing can ensure timely delivery packets of “important” flows. Low priority flows, however, can be starved of resources if there is a continual flow of traffic into higher priority queues.
Drop Policy: Buffer queues resolve contention issues at the network (egress) interface, however when networks are very busy there is contention for space in the queues themselves. When queues become full, packets must be dropped. The simplest drop policy is drop-from-tail. The router drops packets arriving at an egress link if its buffer is full. Like the FIFO scheduling policy, drop-from-tail can lead to unfairness as it favours badly behaved flows over well behaved flows. Furthermore, drop-from-tail tends to cause global synchronisation. TCP flows can undergo oscillatory behaviour because their congestion avoidance stages are in phase.
Active queue management (AQM) methods drop packets before buffers overflow. This “warns” traffic sources about impending congestion periods. A dropped packet causes a (TCP) source to throttle back its transmission rate. An example of an AQM is Random Early Detect (RED). RED drops packets from the queue with a probability determined by the current level of buffer occupancy. The higher the buffer occupancy, the higher the drop probability. RED is deemed to be fairer than drop-from-tail because heavy flows will have more packets in the queue and are, therefore, more likely to have their packets dropped (and their rates throttled at the source). RED also avoids the global synchronisation problem that occurs with drop-from-tail.
Work-conserving Policy: Network links are either work-conserving or non-work- conserving. A work conserving link is only idle when there are no packets in the buffer queue, otherwise packets are transmitted without delay. An example of a non-work-conserving link would be a link which incorporates a packet shaper.
Consider a customer that has a traffic contract with a network provider. The network provider must honour the contract and ensure the necessary resources are available in the network to meet the customer’s flow requirements. Conversely, the customer will have agreed to a flow rate. The network provider may police the customer’s flow rate and drop any packets that exceed that rate. In order to avoid packet drops, the customer may elect to shape its traffic to ensure it does not exceed the flow rate. To do this the edge router must buffer and delay packets to ensure the flow rate is not exceeded. In this case, the customer’s link to the network provider is non-work-conserving.
WiFi network interface could also be described as non-work-conserving because the 802.11 MAC protocol introduces inter-frame spaces (IFSs) in order to prioritise frames and uses exponential back-off schemes to minimise collisions. Furthermore, power save schemes will buffer frames until the receiver has woken up from some sleep state.
In this article we have presented a taxonomy of traffic management policies and introduced a few of the many policies available. Traffic management is not a solution to congestion problems, rather it enables network operators to optimise network resources and administer fairness throughout its community of users.
References
[1] V Alwayn. Advanced MPLS Design and Implementation. Cisco Press, Indianapolis, 2002.
[2] D Comer. Internetworking With TCP/IP Volume 1: Principles, Protocols, and Architecture. Prentice Hall, Englewood CLiffs, NJ, 5 edition, 2006.
[3] Alan Holt and Chi-Yu Huang. 802.11 Wireless Networks, Security and Analysis. Springer, London, UK, 2010.
[4] T M Thomas. OSPF Network Design Solution. Ciscopress, Indianapolis, 1998.
by Alan | 8 September 2011
Disclaimer: The opinions expressed in this blog represent those of the blogger or original article writer (if reproduced or linked to), and not those of IP Performance Ltd or IP Performance Ltd's subsidiaries, vendors, distribution channel or other business partners. Furthermore, all content being the responsibility of the individual blogger or original author, it is not intended to malign any religion, ethnic group, club, organisation, company, or individual. All data and information provided on this site is for informational purposes only. IP Performance Ltd makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.
