The idea
Scheduling and shaping decide how packets are handled once they are in the network. Resource management decides what the network is willing to promise in the first place. A link cannot support demands beyond its capacity, so a network that guarantees quality has to be able to say no.
How it works
Principles of QoS guarantees
The lecture’s example is a 1 Mbps IP phone and FTP sharing a 1.5 Mbps
link. Bursts of FTP can congest the router and cause audio loss, and we want
to give audio priority over FTP. Four principles follow.
- Marking and classification. The router needs packet marking or classification to distinguish between classes, and a router policy to treat packets accordingly.
- Isolation. If an application misbehaves, for example audio sending above its declared rate, policing forces the source to adhere to its bandwidth allocation. Provide protection (isolation) for one class from others.
- Efficiency. Fixed, non-sharable bandwidth is an inefficient use of bandwidth if a flow does not use its allocation. While providing isolation, use resources as efficiently as possible.
- Call admission. The network cannot support traffic demands beyond link capacity. A flow declares its needs, and the network may block the call, like a busy signal, if it cannot meet them.
How it works
Resource management and admission control
Flows need resources: buffers, capacity, CPU time and so on. QoS improves if these resources are guaranteed beforehand, and the lecture names two resource-reservation models: Integrated Services and Differentiated Services.
Admission control is a mechanism a router or switch uses to accept or reject a flow, based on predefined parameters called flow specifications. Before a router accepts a flow it checks:
- whether its capacity (bandwidth, buffer size, CPU speed and so on) can handle the new flow, and
- whether its previous commitments to other flows can handle the new flow.
How it works
Integrated Services (IntServ)
The traditional Internet only provides best-effort delivery to all users, but some applications such as real-time video need a minimum bandwidth. IntServ is an architecture for QoS guarantees in IP networks for individual application sessions or flows, so it is flow-based. Resources are explicitly reserved for a given data flow. Routers maintain state about allocated resources and about the QoS requests of different flows, and they admit or deny new call setup requests.
An arriving session must:
- Declare its QoS requirement with an R-spec, which defines the QoS being requested (buffer, bandwidth and so on).
- Characterise its traffic with a T-spec, which defines the traffic characteristics of the flow using token bucket parameters. See Traffic shaping.
- Use a signalling protocol to carry the R-spec and T-spec to the routers where reservation is required. That protocol is RSVP, the Resource Reservation Protocol.
The lecture’s scenario shows resource reservation with call setup and signalling, a traffic and QoS declaration, per-element admission control and QoS-sensitive scheduling such as WFQ. See Scheduling.
Two service classes are offered:
- Guaranteed service is designed for real-time traffic that needs a guaranteed minimum end-to-end delay. It guarantees that packets arrive within a certain delivery time and are not discarded if flow traffic stays within the T-spec.
- Controlled-load service is designed for applications that can accept some delay but are sensitive to an overloaded network and to the danger of losing packets.
How it works
Differentiated Services (DiffServ)
The lecture raises two concerns with IntServ:
- Scalability. A router must keep information for each flow.
- Service class limitations. There are only two types, guaranteed and controlled-load.
DiffServ answers them by moving the main processing from the core of the network to the edge, which solves the scalability problem, and by changing per-flow service to per-class service.
| IntServ | DiffServ | |
|---|---|---|
| Unit of service | Per flow | Per class |
| Resources | Explicitly reserved, virtual paths built by bandwidth reservation | No reservation, traffic differentiation and priority |
| Router state | State kept for each flow | Main processing at the network edge |
| Signalling | RSVP carries R-spec and T-spec | Not mentioned in the lecture |
Where marks get lost
Do not credit DiffServ with guarantees
The lecture describes DiffServ as differentiation or priority without reservation. Only IntServ reserves resources. A question asking which model provides explicit per-flow reservation wants IntServ.
In the exam
- Four principles with the phone and FTP example for the first three.
- Admission control checks two things: capacity, and existing commitments.
- IntServ vocabulary: R-spec, T-spec, RSVP, guaranteed service, controlled-load service, flow-based, router state.
- IntServ versus DiffServ: per-flow with reservation, against per-class without. The reasons for DiffServ are scalability and the narrow set of service classes.
Aside
The lecture’s slide titled “Service Classes” and the traffic classification diagrams are figures that do not survive text extraction. This page has not filled them in from outside knowledge, so there is no DiffServ marking detail here.
Check yourself
- Four principles: mark, isolate, use resources efficiently, admit or block.
- Admission control accepts or rejects a flow against capacity and existing commitments.
- IntServ reserves resources per flow using R-spec, T-spec and RSVP, offering guaranteed and controlled-load service.
- DiffServ works per class at the edge, without reservation.