IP Networks

---

Provisioning QoS in an IP network (Wi-Fi, Ethernet and the Internet are all IP networks) is all the more difficult because these networks are "dumb." In most instances, designers focus on provisioning QoS via more bandwidth, rather than on building more intelligence into the network. Here's why.

TCP/IP is built into the UNIX operating system and is used by the Internet, making it the de facto standard for transmitting data over networks. TCP/IP is a suite of communication protocols allowing communication between groups of dissimilar computer systems from a variety of vendors. This suite of protocols is designed to ignore the kind of traffic it is carrying, and to concentrate on getting that traffic to the right place.

IP (Internet Protocol) moves packets of data between nodes. TCP (Transmission Control Protocol) is responsible for verifying delivery from client to server, and so it provides packet retransmission in case of failure. However, UDP (User Datagram Protocol), which is also part of the TCP/IP suite, doesn't retransmit missing packets, leaving it up to the application that's using UDP to decide whether it needs the missing pieces or not.

Networks (wired and wireless) are "bursty" by nature. This is because data that traverses the network isn't constant—network users do not constantly upload and down load data. For example: if you are viewing a web page and you hit the enter key, data is transmitted, and the image and text load. Once loaded, the transmission stops while you read the web page. At that point the bandwidth is again sitting idle, and utilization is back at zero. This cycle continuously repeats itself throughout the networking environment. Furthermore, since packet loss is often the result of congestion or rerouting in the network, packet loss commonly occurs during bursts of activity.

Figure 16.1: TCP/IP stack as it relates to the Layers of the TCP/IP Network Model (note that this model has fewer layers than the ISO/OSI Reference Model, but they encompass the same things).

The degree of a network's "burstiness" impacts the network's ability to provide QoS, especially voice quality. While the packet loss-concealment algorithms used by most Voice over IP (VoIP) implementations (and even other types of bandwidth-sensitive applications) can disguise isolated lost packets, they are much less effective when a series of packets is lost. It doesn't take a lot of dropped packets in a voice call to make a conversation sound choppy (or for a video stream to delay and jitter). Of course, with the right design and attention to outside influences (interferers, blockage, etc.), a substantial majority of collisions or dropped packets can be reduced, increasing a network's "quality" throughput quotient.

With VoIP, however, the problem of QoS transcends "bandwidth." For example, in the May/June 2002 issue of IEEE Internet Computing is a discussion that deals with VoIP QoS in detail; however, the emphasis isn't on bandwidth, but on delay and jitter. That's because just 56 Kbps of bandwidth is needed to convey an uncompressed G.711 voice signal through a network. But when you take that voice stream, chop it up into packets, and push it through a network that is also being used for data transport, video delivery and other data, problems can and do occur between the transmitting node and receiving node. This makes it difficult to guarantee that the voice packets will arrive at their destination within an average of 10 ms of each other. If you can't ensure that those packets will arrive within 10 ms of each other, the voice quality degrades below that defined by G.114 and G.131 (the standards for voice telecommunication established back in the 1950s).

Many recent packet-switched voice systems have relaxed the end-to-end packet delay tolerances to about 150 ms; such longer delays, however, should be the exception rather than the rule. (Human hearing tolerates delays up to 150 ms.)

Coping with Burstiness

In principle, IP networks, and thus Wi-Fi networks, can support interactive, multimedia traffic, and even the long-heralded convergence of the communications infrastructure. This "convergence", however, that has been delayed—in all IP networks—due to a lack of adequate capacity to support "real-time" services.

In recognition of the growing need for support of bandwidth intensive real-time services such as voice-over-IP, network managers have begun considering an investment in substantial upgrades to the transport capacity of their network backbone. But do they really need to take that step? The jury is still out on that question.

Some experts suggest that overprovisioning is the optimal approach to addressing the QoS issue. For example, Sprint says that none of their links are more than 40 percent filled with traffic, thus eliminating any congestion on the backbone. But other experts argue that capacity will remain scarce, and hence it is worth implementing bandwidth economization methods by means of QoS techniques. Also, as you will learn, overprovisioning will not always solve a QoS issue in a Wi-Fi network.

A second concern is the optimal utilization level for the network. IP network traffic is more bursty than voice telephony traffic, which suggests that the optimal utilization rate for an IP network is likely to be lower than for a telephone network, because of the need to provision to handle peak loads (or else suffer quality of service degradation during peaks). These two issues are related because the lower the optimal utilization level, the greater is the required investment in overprovisioning in order to sustain any given level of quality of service. The greater the cost of using overprovisioning to address the QoS problem, the more attractive are the mechanisms that facilitate efficient allocation of scarce capacity.

A standard mechanism for addressing the problem of bursty traffic is to aggregate sources in the hope of smoothing peaks (i.e. peaks are uncorrelated). The potential need to support high-bandwidth, time-sensitive traffic means that even relatively small-scale economies may be quite valuable. Interestingly, if the network is used extensively for high-bandwidth, time-sensitive applications (streaming audio and video in particular), the addition of such services may actually alleviate the "bursty" problem, since by their very nature these applications reduce the burstiness of the aggregate traffic.

---