Quality of Service on Wired Networks

The benefit of packet networks is that they are incredibly flexible. The ironic thing about the transfer from circuit networks to packet networks, however, is that the best-effort nature of packet delivery requires that packet networks develop the quality-of-service sophistication that was not needed for circuits networks. On a circuit, there is always room for a high-quality call, if there is room at all. On a packet-based network, however, it is very difficult to tell whether that call can just be squeezed in, or whether problems will arise.

There are two general methods for solving the quality-of-service problem with packet networks. Both methods are based on notions designed for IP, to ensure the simplest network that can deliver on the promises.

Integrated Services

The concept of integrated services is that the quality-of-service mechanisms are integrated directly into the forwarding network. Integrated services are based on the notion of resource reservations, similar to with circuit networks. The difference between circuit-oriented resource reservations and integrated services reservations is that the latter can accommodate a nearly infinite variety of packet rates, sizes, types, and behaviors.

Integrated services is based on the protocol called RSVP, the Resource Reservation Protocol in RFC 2205 (though named to sound like the phrase répondez, s'il vous plaît, as appropriate for reservations). The idea is rather simple. A receiver that needs to send a flow of a certain type requests the ability to get that flow with a specific quality of service. The sender uses a multicast group to send out specific messages, called PATH messages, to announce the availability of a stream. When a listener wants to join, it sends a response called a RESV (for reservation) directly back to the sender. Along the way, the intervening routers on the path have the responsibility of listening in on that protocol, and trying to provide just that quality of service.

The crux of the mechanism is the voluntary announcing of the flow qualities required using a format known as a traffic specification, or TSPEC. The TSPEC for RSVP is shown in Table 1. The Token Bucket Rate is a floating-point number that represents the amount of bytes per second that the flow is expected to take. The Token Bucket Size is a floating-point number specifying the amount of tokens, in bytes, that a flow can accumulate. This is something like a measure of the backlog. Token buckets work to regulate a flow. The idea is that the flow is given tokens at a fixed rate, one token per allowed byte. Thus, a flow that was admitted for one kilobyte a second will get 1000 tokens a second. The bucket has a maximum capacity, the size, to prevent a flow from getting an infinite hall pass to transmit if it has been idle for a while and not using its resources. Every byte that passes by from that flow needs a token to continue, and takes it from the bucket. Once the buckets are done, the network can either buffer the packet until it gets a token, or police the flow by dropping that packet. RSVP works usually under the latter condition. However, RSVP also endeavors to ensure that the flows that are within their limits get to use the resources before best effort traffic.

Table 1: RSVP TSPEC Format 

Token Bucket Rate	Token Bucket Size	Peak Data Rate	Minimum Policed Unit	Maximum Policed Size
4 bytes	4 bytes	4 bytes	4 bytes	4 bytes

The Minimum Policed Unit is set to the size of the smallest packet that is used in the flow: for voice or video, this is likely to be an RTP packet. The Maximum Policed Size field specifies the largest packet size that the sender may want to generate.

RSVP is a form of admission control. When the resource requests are made, if any one of the routers cannot support the flow because it has already exceeded its admissible capacity, it will inject a reject message, to inform the listener that its flow's quality of service will not be granted.

RSVP's greatest disadvantage is that it requires all of the routers to keep state—even soft state—on every flow, and to take action based on the behavior of the flow. Because of this, RSVP is not commonly used in voice mobility networks, and the concepts are not used for wireline. The same concepts behind RSVP, however, appear in the context of wireless networks, where the stakes are higher and the number of devices that must maintain state are dramatically reduced (to one base station and one client).