Until a few years ago, the only critical factor on most networks was to transfer data as quickly and securely as possible between endpoints. Computers and network components on the LAN and WAN have been optimized for this purpose. However, this model is useless for Voice or Video over IP (VoIP), because both require low latency and guaranteed constant transmission rates from the network. Both packet loss and jitter can significantly affect the quality of voice transmission delivered to the end user. The Internet Engineering Task Force (IETF) has defined various quality of service (QoS) models for an IP network: best effort, IntServ (integrated services), and DiffServ (differentiated services).

QoS Models

The Internet uses the best-effort model, which offers minimal QoS assurance. For business networks, this model also applies if no QoS policies have been configured or the infrastructure does not support QoS. With the best-effort model, there is no guarantee that the packets will be delivered. Additionally, all packets have the same priority and are therefore treated identically. Packets from a VoIP stream are therefore processed with the same priority as those from an email session. Unfortunately, many companies that use VoIP still use the best-effort model because the infrastructure is not properly configured or QoS is simply not supported.

The IntServ model reserves bandwidth in the relevant network path, which guarantees the necessary bandwidth for mission-critical applications from end to end. IntServ uses signals for the QoS model: The end host signals the network's QoS requirements. Each individual communication stream has to request resources from the network. Edge routers use the Resource Reservation Protocol (RSVP) to signal that the appropriate bandwidth should be reserved for each flow on the network. One major drawback of the IntServ model is that each device in the path a packet takes must be fully compatible with RSVP, including routers, servers, personal computers (PCs), and other equipment.

DiffServ service classes provide the necessary traffic characteristics to the various applications on an end-to-end basis. RFC 4594 defines 12 service classes: two for network operation and administration and 10 for applications and services.

Service Class Mechanisms

A service class means a volume of traffic that imposes specific requirements (in terms of delay, loss, and jitter) on the network. Conceptually, a service class refers to applications with similar characteristics and performance requirements. The service classes are defined in a differentiated services (DS) domain but can also be implemented across multiple DS domains.

A service class defines the required characteristics of a traffic aggregate that is computed from the use of certain per-hop behaviors (PHBs), as defined in RFC 2474. The handling of a traffic aggregate within a domain (per-domain behavior) can be defined according to RFC 3086. Some mechanisms are available to implement the service classes, which I discuss in more detail later.

In queuing, a queue is formed if more requests are sent to a system per time unit than the system can process in the same time. The data packets to be transferred are delayed while being buffered in a queue because they are not forwarded in a timely manner as a consequence of insufficient bandwidth or low priority.

Priority queuing is a combination of a series of queues and a scheduler that empties the queues in order of priority. The scheduler checks the queue with the highest priority and forwards a packet stored therein for processing. Next, the scheduler checks the queue with the next lowest priority and so on. In a priority queue system, a packet in the queue with the highest priority experiences a predictable delay.

Rate queuing, or the rate-based queue system, comprises a combination of queues and a scheduler that empties each queue at a certain rate. In a rate-based queuing system, such as Weighted Fair Queuing (WFQ) or Weighted Round Robin (WRR), the delay experienced by a packet in a particular queue depends on the occupancy of the queues with which it competes.

Active Queue Management (AQM) is a management method for dropping and flagging packets in a queue. An example of such a procedure is Random Early Detection (RED). This mechanism pre-emptively drops packets before the buffer becomes completely full. A queue is assigned a minimum threshold, which is the average queue size below which no packets will be dropped, and a maximum threshold, which is the average queue size above which all packets will be dropped.

The queue algorithm ensures that the queues are only ever filled to an average extent (depth), which varies between the minimum and maximum thresholds. If the average queue depth is below the minimum threshold, all packets are queued up. If the average queue depth approaches the maximum threshold value, the probablility an incoming packet is dropped increases. If the average queue depth is between the thresholds, a randomly selected subset of the incoming traffic is flagged or dropped.

A variation of this algorithm is used in Assured Forwarding PHB (RFC 2597). In this case, several differentiated services codepoint (DSCP) markers are mixed in a common queue. Different minima and maxima are configured separately for the different DSCP values, so that traffic exceeding a specified rate when entering the queue is more likely to be dropped or flagged than traffic that is within the agreed upon rate.

In traffic conditioning, incoming traffic is measured in line with a policy on the access router to the network and dropped or flagged, ensuring that the network flows are already formed at the edge of the network (Figure 1). For this reason, these processing methods are known as "traffic conditioners." The following traffic conditioners can be used to provide differentiated services:

• Class Selector (CS) PHB: A single token bucket meter provides one data rate plus burst size control.
• Expedited Forwarding (EF) PHB: A single token bucket meter controls the data rate and burst sizes.
• Assured Forwarding (AF) PHB: Typically, two token bucket meters are configured to control behavior as per a two-rate three-color marker (RFC 2698) or single-rate three-color marker (RFC 2697). The two- and three-color markers are used to enforce two data rates, whereas the single-rate three-color marker is used to enforce a fixed rate with two burst lengths.

Figure 1: Data flows can be controlled individually by QoS mechanisms on the network.

The DSCPs have values from 0 to 63 that are inserted into the IP header, thus marking the corresponding traffic class. Currently, half of the DSCP values are reserved for standardized services. The other half are available for local definitions. The described mechanisms are used for specific features for forwarding different types of traffic depending on the requirements of the application. DSCPs are only used for classification, not prioritization, which means that a higher numerical value does not necessarily correspond to a preferred treatment. Instead, a DSCP relates to a forwarding behavior (PHB) that specifies how to handle a packet.

Understanding Forwarding Behavior

Differentiated services – as the sum total of all DSCPs – provide a general architecture for the implementation of a variety of services. For practical purposes, three basic forwarding behaviors are defined, the first of which is default forwarding (DF). The forwarding behavior for each traffic class is described in RFCs 2474 and 2309. The network operator promises its users that incoming transmission requests will be handled as quickly as possible and to the best of its ability within the limits of the resources available and minimal QoS assurance. On packet-switching networks, best effort means forwarding all incoming packets as long as free transmission capacity still exists on the network. Error-free and complete transmission are not guaranteed. If the capacity is fully utilized at a certain point in the transmission path, congestion inevitably occurs.

The second behavior, Assured Forwarding (AF) according to RFC 2597, offers four classes of forwarding behavior that you can specify for the marker. Table 1 shows the classes, the three drop priority levels for each class, and the recommended values (decimal and binary) of AF codepoints.

Finally, expedited forwarding (EF) as per RFC 3246 guarantees that packets with EF codepoint 46 receive the best handling available on the network. Thus, packets with codepoint 46 are guaranteed to receive preferential treatment from all DiffServ routers on their way to their destination.