QoS Models

1. QoS models and their use

The original IP service forwards packets without reserving resources or distinguishing application requirements. The Best-Effort model was adequate for uses such as email and file transfer. High-definition video conferencing, online gaming, and large cloud backups use a link in different ways, so one forwarding rule does not describe every requirement. The chosen model determines whether the network records requirements for a flow or an aggregate.

A QoS architecture defines rules for classifying, prioritizing, and managing traffic across a network. A model describes how an application receives a particular treatment. The main models are Best-Effort, resource reservation with Integrated Services (IntServ), and class-based Differentiated Services (DiffServ). They differ in service parameters, state held by routers, and responses to congestion.

2. The Best-Effort model

The Best-Effort model is the default IP service. It forwards packets according to available resources and does not reserve parameters for an individual flow. Devices can change their treatment as load and configuration change.

How the Best-Effort model works

A simple best-effort implementation can use a first-in, first-out (FIFO) queue. The model itself does not mandate that algorithm. Packets are forwarded according to available resources and device configuration, without guarantees for bandwidth, delay, or delivery. Another scheduler can order packets by priority or current queue state.

• No Guarantees: There is no guarantee of bandwidth, no protection against packet loss, and no predictable level of latency or jitter.
• Shared resources: Traffic streams use common link capacity, while the device implementation determines how that capacity is divided. Without reservation, the device can allocate resources according to its current policy.
• Simplicity and scalability: The model requires no reservation or per-flow state. This limits device requirements and supports operation in large networks. A router can serve traffic without signaling for each session.

Limitations of the Best-Effort model

The model suits applications that tolerate delay and variation, such as email and standard web browsing using TCP reliability mechanisms. TCP can retransmit missing data, preserving stream integrity at the cost of transfer time. Interactive real-time applications need additional traffic-treatment rules. In Voice over IP, a packet delivered after its part of the conversation cannot improve playback. The router has no playback deadline from the receiver. Variable best-effort parameters make this traffic difficult to plan.

3. Integrated Services (IntServ)

The Integrated Services model, often called IntServ, describes explicit and measurable service parameters for individual application flows. Its basis is resource reservation and admission control for new requests. Each flow receives parameters associated with the selected service class.

Core concepts of IntServ

• Per-flow state: IntServ treats an application data stream as an individual flow. A flow can be a VoIP call, a video-conference session, or another distinct stream. Routers identify its packets and store the parameters of the associated service. Source and destination addresses together with port numbers are commonly used for identification.
• Explicit resource reservation: The application signals its requirements and requests bandwidth and buffer space along the complete path from source to destination. Devices on the path check the request before serving the flow. The reservation also covers queue treatment and the delay calculation.
• Admission Control: Each router along the path performs admission control. When a reservation request arrives, the router checks if it has sufficient available resources to meet the new request without compromising the guarantees already made to existing flows. If it has the resources, it accepts the reservation; if not, the request is rejected, and the application is notified that the desired quality of service is unavailable. Rejecting a new request protects established reservations.

The Role of RSVP (Resource Reservation Protocol)

The signaling mechanism used to make these reservations in an IntServ architecture is the Resource Reservation Protocol (RSVP). RSVP is a network-control protocol, not a transport protocol. It uses soft state refreshed by periodic messages. The process uses PATH and RESV messages:

1. The sending application sends an RSVP PATH message toward the destination. The message follows the data route and causes each router to record path state used to direct RESV toward the sender. PATH does not reserve resources.
2. When the receiving application gets PATH, it responds with an RSVP RESV message toward the sender along the recorded path.
3. As RESV passes through each router, the router performs admission control. If resources are available, it updates the scheduler and reservation state, then forwards RESV to the next router. A rejection at any router stops reservation setup.
4. If all routers accept the reservation, the flow receives the agreed end-to-end service, and the application can send traffic that conforms to its profile.

IntServ scalability

IntServ provides parameters for individual flows but requires reservation state and admission control in routers. The state includes service parameters and information needed to treat each flow. In a large network such as the internet, core routers handle a large number of flows at once. A reservation record for every flow increases memory and processing requirements. RSVP refresh messages also increase signaling traffic. Each participating router must process reservation updates throughout the service lifetime. IntServ is therefore rarely deployed in large public networks and is more often found in smaller, controlled environments for specialized applications.

4. Differentiated Services (DiffServ)

The Differentiated Services model, or DiffServ, limits state by grouping traffic into classes. It focuses on prioritization and differentiated treatment rather than reservations for every flow. Classification and marking take place at the domain edge, while PHBs are applied to traffic aggregates inside the domain. Interior nodes operate on classes instead of separate records for every application.

Core concepts of DiffServ

• Traffic classification and marking: An edge router classifies traffic into a defined class using policy, such as source or destination IP address, port number, or application. It then sets a value in the DS field of the IP header. The edge can also meter traffic and re-mark packets outside their profile.
• The DSCP field: Marking uses the 6-bit Differentiated Services Code Point (DSCP)in the IP header's DS field. The value selects a PHB within a domain whose mapping includes that codepoint. The marking remains in the packet header across subsequent hops within the domain unless a boundary node changes it according to policy.
• Per-Hop Behaviors (PHBs): Routers inside the domain can select a PHB from DSCP without maintaining state for every flow. A Per-Hop Behavior (PHB) covers queueing, scheduling, and congestion treatment. A PHB describes observable treatment, while the implementation can use different algorithms.

Common per-hop behaviors

Standard PHBs include:

• Default Forwarding (DF PHB) / Best-Effort: This is the standard best-effort treatment, typically marked with DSCP 0.
• Expedited Forwarding (EF) PHB: Intended for traffic requiring low loss, delay, and jitter, such as VoIP. A strict priority queue is one EF implementation, but the specification describes observable treatment rather than one scheduling algorithm. The service model resembles a virtual leased line. EF traffic needs edge policing so it does not dominate other classes.
• Assured Forwarding (AF) PHB: This PHB defines four service classes, and within each class, three drop precedences: low, medium, and high. A domain can assign high-priority data to a selected class. During congestion, packets with higher drop precedence within that class are discarded first. Bandwidth allocation between classes follows domain policy.

DiffServ scalability

Interior routers check DSCP and select a PHB, while classification and conditioning usually take place at the domain edge. Limiting state to traffic aggregates makes QoS easier to deploy in large networks. The core does not need a separate reservation for every flow. Each packet is handled according to the domain's configured mapping. The scope of use depends on domain policy and configuration.

5. Comparison of QoS models