|
|
Inherent characteristics of data flows |
| All traffic flows are subject to a certain amount of delay. Some flows are more sensitive to delay than others, particularly interactive traffic like voice and video. The following figure outlines some of the more common areas where delay is encountered in a VOIP network. Delay sources are either fixed or variable. |
As seen in the figure above, delay can come from several sources. Codec, packetization, serialization, propagation and network switching delay are all forms of fixed delay. This means they cannot be decreased with any of the Quality of Service Tools. Queuing delay is one of the only forms of delay that is considered variable and can be affected by the many Quality of Service tools available.
Codec delay is a form of fixed delay. Pulse code modulated samples are created during the process of converting traditional TDM based voice signals into digitized speech for VOIP. Digital signal processors (DSP) are used to compress those samples into smaller chunks. Using this method, one can realize a tremendous decrease in the bandwidth required to complete a call. There are various coding schemes available. Their best and worst case coding delays are listed below. G711 is a popular coding scheme. It does not compress the PCM sample and therefore it does not experience a codec delay.
| Codec | Rate | Minimum Sample block | Worst Case Codec Delay |
| ADPCM, G.726 | 32 Kbps | 10 ms | 10 ms |
| CS-ACELP, G.729A | 8.0 Kbps | 10 ms | 10 ms |
| MP-MLQ, G.723.1 | 6.3 Kbps | 30 ms | 20 ms |
| MP-ACELP, G.723.1 | 5.3 Kbps | 30 ms | 20 ms |
The time it takes for a coded/compressed voice signal to be converted into an IP packet is called packetization delay. This form of delay is also considered a fixed source of delay. Cisco recommends that you strive for a packetization delay of no more than 30 ms. The chart below shows the associated packetization delay of each codec type.
| Codec | Rate | Payload Size (Bytes) | Packetization Delay (ms) | Payload Size (Bytes) | Packetization Delay (ms) |
| PCM, G.711 | 64 Kbps | 160 | 20 | 240 | 30 |
| ADPCM, G.726 | 32 Kbps | 80 | 20 | 120 | 30 |
| CS-ACELP, G.729 | 8.0 Kbps | 20 | 20 | 30 | 30 |
| MP-MLQ, G.723.1 | 6.3 Kbps | 24 | 24 | 60 | 48 |
| MP-ACELP, G.723.1 | 5.3 Kbps | 20 | 30 | 60 | 60 |
This form of delay is variable. It's probably one of the only forms of delay that can be minimized with QOS tools. Before a packet is serialized onto an outgoing interface, it gets sent to a queue. Default queues use a FIFO (First In First Out) method of servicing those queues. This type of queuing doesn't bode well for delay sensitive traffic. Large packet trains tend to fill up the queue and the delay sensitive traffic must wait for the entire train to be transmitted before it gets its turn. A good portion of this tutorial will focus on the Cisco QOS tools available to us for optimizing output queuing.
Serialization delay is the amount of time it takes to actually service a queue and place the bits onto the wire for transmission. This is another fixed form of delay in networks. The delay will vary based on the clocking speed of the interface. Obviously, a 56k circuit will have a higher serialization delay than a T-1 circuit. The table below will illustrate the different delays (in seconds) with reference to the interface speed.
| Frame Size (bytes) | Interface Speed (Kbps) | |||||||
| 19.2 | 56 | 64 | 128 | 256 | 384 | 512 | 768 | |
| 38 | 15.83 | 5.43 | 4.75 | 2.38 | 1.19 | 0.79 | 0.59 | 0.4 |
| 48 | 20 | 6.86 | 6 | 3 | 1.5 | 1 | 0.75 | 0.5 |
| 64 | 26.67 | 9.14 | 8 | 4 | 2 | 1.33 | 1 | 0.67 |
| 128 | 53.33 | 18.29 | 16 | 8 | 4 | 2.67 | 2 | 1.33 |
| 256 | 106.67 | 36.57 | 32 | 16 | 8 | 5.3 | 4 | 2.67 |
| 512 | 213.33 | 73.14 | 64 | 32 | 16 | 10.67 | 8 | 5.33 |
| 1024 | 426.67 | 149.29 | 128 | 64 | 32 | 21.33 | 16 | 10.67 |
| 1500 | 625 | 214.29 | 187.5 | 93.75 | 46.88 | 31.25 | 23.44 | 15.63 |
| 2048 | 853.33 | 292.57 | 256 | 128 | 64 | 42.67 | 32 | 21.33 |
This form of delay is usually completely out of the control of a local network engineer. This is the delay added by your service provider when connecting sites together. Typically, connections are carried across public frame-relay or ATM links. Frame-relay service providers have published a fixed network delay of 45ms with an added variable delay of 65ms. So, in a worst case scenario, you can have up to 65ms of delay from a frame-relay network. Worst case scenario would probably be realized by two sites that are geographically spread far apart. You may realize lower delays for connections that are closer together. This delay is an accumulation of queuing delay in the network switches and propagation delay. Propagation delay is the amount of time it takes for the electrical signals to reach one end-point to the other. This is typically the speed of light. A general rule of thumb is to add 10 microseconds of delay for every mile of distance. This is based on the ITU recommendation G.114
Variation in delay is defined as jitter. IP phones expect an isochronous flow of traffic. Isochronous packet flows arrive at equal intervals of time. Therefore, VOIP packets should arrive at an IP phone in evenly spaced time intervals. Usually, this is every 20ms. Any variation in that arrival of a packet creates jitter. Jitter is not good for a voice packet train. If a packet arrives late, it's better for the phone to drop the packet than it is to play it. Imagine if someone where talking to you and had their consonants or vowel sounds out of order. You wouldn't be able to understand them. If VOIP packets were played into an IP phone out of order you would have the same result. You cannot simply hold the packets in queue and put them in order when they all arrive. This would create choppy voice and or long pauses between speech. There has to be a way to virtually guarantee that packets will arrive in order and at an evenly spaced time interval. This is where QOS tools come into play. This tutorial will explorer the different ways of making this possible.
Packet loss in a VOIP network is for the most part not tolerated at all. Dropped packets will create choppy voice. Some of the more advanced codecs, like G.729, can make assumptions as to what the lost packet might have been. The most a codec can predict is 30ms of speech. Anything more than this will surely cause voice degradation.
There are two main causes of lost packets. The first cause would be from a degraded circuit. Errors on circuits will cause failed CRC error checks and the router will throw the frames in the bit bucket. Since UDP doesn't have built in retransmissions like TCP, the packet will not be re-transmitted. It wouldn't matter anyway since the VOIP packet would already be useless due to excessive delay. There's nothing that QOS tools can do for this example. You must have the errors on the circuit corrected.
The second source of packet loss would be caused by queue drop. When router output queues reach their maximums, they start throwing away packets. This is commonly called tail-drop. If QOS is not in place, the router doesn't care which packets it throws away. It will toss packets from the end of the full queue. This form of packet loss is almost always inevitable. Fortunately, there are ways to prioritize traffic in the queues while adjusting drop thresholds on pre-defined traffic classes. We will learn ways to accomplish this later in the tutorial.
|