SIZE OF PACKETS AND KINDS OF TRAFFIC IP SUPPORTS
We continue analyzing the attributes of the Internet by examining the traffic characteristics relating to average size of the protocol data unit (packet), see Figure 2-4(a). The most common packet size is 40 bytes, which accounts for TCP acknowledgements (ACKs), finish messages (FINs), and reset messages (RSTs). Overall, the average packet sizes vary from 175 to about 400 bytes, and 90 percent of the packets are 576 or smaller. Ten percent of the traffic is sent in 1500-byte sizes, which reflects traffic from Ethernet-attached hosts.
Figure 2-4. Traffic characteristics of the Internet
The other common occurrences are packet sizes of 576 bytes (6 percent of the traffic), and 552 bytes (5 percent of the traffic). These sizes reflect common protocol data unit sizes used in the Internet protocols.
In Figure 2-4(b), the type of traffic carried by IP is shown. Almost all the traffic is TCP, followed by UDP, then ICMP. Other traffic encapsulated directly in IP accounts for very little of the Internet traffic.
The significance of these facts to VoIP is as follows. First, it is important to use small packets for voice traffic. If a packet is lost in the network, the small packet is less likely to contain significant parts of a speech signal. The idea is to divide and conquer. Most low-bit rate voice coders are designed to produce very short voice packets, usually no more than 10–30 ms in duration, and 10–30 bytes in length.
The other reason for a small packet is that it permits the processing node, such as a router, to examine and operate on a small unit of information quickly: it does not have to wait very long for the bits to propagate through the incoming interface. In contrast, a long packet means it takes a while for the bits of the entire transmission to arrive and therefore to be processed.
As you can see, the Internet has been calibrated to use relatively large packets. The fact that almost 50 percent of the packets transported in the Internet are only 40 bytes is not significant. They are not for user traffic, but for connection management operations for TCP.
If a substantial amount of Internet traffic becomes voice traffic, it will require a concomitant increase in Internet capacity, because the smaller packets will consume significantly more of the overall bandwidth: The ratio of overhead to user payload will increase. Some people express concern about this situation, but I do not think it will be a major problem, because the increased use of high-speed SONET links, and the migration to wave division multiplexing (WDM) will provide the needed bandwidth.
A potentially bigger problem is the increased load on the routers in the Internet. After all, the router has to spend as much time processing the fixed-length header of a 10-byte packet as it does in processing the same length header of a 576-byte packet. This situation can be ameliorated by multiplexing two or three voice samples inside one packet, but taking care not to expand the overall packet size such that succumbs to the large packet problem described earlier.
Moreover, with the migration to high-speed gigabit routers, I believe the overall latency in the Internet will continue to improve.
Figure 2-4(b) points to another potential problem of supporting voice traffic in the Internet. The vast majority of user traffic is transported with the TCP header. As explained later in this chapter, TCP provides extensive support for traffic integrity operations: (a) error checks, (b) acknowledgments of traffic, (c) retransmissions of errored traffic, and (d) flow control.
But voice applications need not use TCP; in fact, they should not use it, because the TCP support features introduce too much delay in the overall procedure, and it is not practicable to achieve real-time performance if some of the errored packets are retransmitted. The overall delay, would be over 400–500 ms, clearly beyond the RTT that is acceptable for speech.
The potential problem is related to TCP flow-control mechanisms. One feature implemented in many TCP products is the ability of TCP to back off from sending traffic when the Internet is congested and experiencing poor RTT.
In this regard, TCP is a "courteous" protocol. It waits if necessary and does not intrude its presence (its packets) into a congested network. But UDP, on which VoIP operates, has no such qualms. It is a "discourteous" protocol in that is has no back-off mechanisms. It will continue sending traffic even if the network is congested.
So, if the network is congested, TCP stands by the door at the network, and does not enter. Indeed, TCP opens the door, and UDP goes through it!.
As seen in Figure 2-4(b), UDP accounts for only 3 percent of traffic that is placed directly in the IP datagram. However, if voice (and video) become heavy users of the Internet, then it is possible that the TCP users will experience degraded performance during periods of high activity of the real-time traffic.
Earlier, I said it is a potential problem. If the Internet and internets are built with sufficient bandwidth, there will be no problem.