Results

Introduction

When you bring up the subject of QOS, or Quality Of Service, most people immediately think of some sort of queuing mechanism. While queuing is a part of QOS, it is certainly not a major part. With that in mind, what exactly does QOS mean to you? Take a moment or two to think about that.

I’ll use a familiar analogy to expose the different areas of QOS to you. Imagine you’re waiting in line at the grocery store. Now imagine that there is only one possible checkout register and many people waiting in line. In other words, a queue has formed and is getting longer since there is only one person checking customers out at a time.

If you’re the store owner, you probably will want to find the most efficient way to service your customers. This may involve some sort of traffic analysis to determine the optimum number of registers you should have open throughout the day. Too many and you risk having having idle cashiers. Too few and you risk having long lines and angry customers. Also, how are your cash registers situated? Do you have a single line that wraps around where customers enter? Maybe you have several lines that customers can enter.

Another service aspect you may consider are things such as how your employees treat customers. A disgruntled employee may give poor service and cause your customers to not come back. A cheery employee can certainly entice customers back, particularly if they provide smooth seamless service (such as walking a customer to an open register after helping them find an item).

Maybe you provide your customers with a rewards card for preferential treatment. Many stores are doing this these days. The rewards can be such things as a “buy 10 get one free” or discounts on merchandise. Regardless of the rewards, the point is to identify who your customers are.

Lastly, while not directly related to your business, there may be times where a shopper’s child either gets lost in the store or exits the store and makes it to the car first. Obviously, you would want a parent and their child together at all times.

As you can see, managing your customers and lines at the registers requires a bit of traffic analysis and classification. Several of the topics mentioned in the analogy directly map to QOS topics for networking. Just to name a few that are represented in the analogy:

• Queuing
• Congestion Management
• Differentiated Services Code Point (DSCP)
• Classification and Marking
• Delay and Jitter

These topics barely scratch the surface of what you can do with QOS but I didn’t want to make too lengthy an analogy. We’ll talk about these topics and more in successive parts to this series. For now, I’ll give you a basic overview of QOS in a network.

Before you read further, you should have a basic understanding of networking principles. If you don’t you may get a little lost. If you see anything unfamiliar you can always leave a comment or check your favorite search engine for answers.

Managing a converged network

QOS really is nothing more than a set of tools to manage a constrained resource: your network. You use QOS tools to manage and affect the four main traffic characteristics in your network:

• Packet loss
• Delay
• Jitter
• Bandwidth

Let’s look at each of these characteristics in closer detail.

Packet Loss

Packet loss can occur for a variety of reasons such as a poor physical medium, failing an incoming frame check sequence (FCS), or even by network security denying packets of a particular type. Any time a packet fails its FCS it is immediately dropped.

Another cause of packet loss is a situation called “tail drop”. This occurs when a packet attempts to get enqueued at the end (or tail) of an interface queue. An example is if you have an interface that has the ability to hold 40 packets (a queue depth of 40). If the queue is full and the 41st packet attempts to enter that interface’s queue, it will be tail dropped. This isn’t particularly harmful to data flows such as web browsing but can be very detrimental to loss-sensitive applications such as voice over IP.

Delay

Delay occurs throughout the network and is particularly troublesome to manage. Delay is nothing more than the latency between when a packet was sent and when it finally arrives at its destination. There are eight different types of delay that can possibly occur:

• Compression Delay
• Codec Delay
• Network Delay
• Shaping Delay
• Forwarding Delay
• Queuing Delay
• Serialization Delay
• Propagation Delay

The compression, network, shaping, forwarding, and queuing delays are variable (meaning they change throughout time) whereas codec, serialization, and propagation delays are fixed. Don’t be intimidated by the terms. I’ll explain them below.

Measuring delay is actually pretty simple. You simply calculate the different delay components from point A to point B and total them up. Note that you cannot calculate the delay components that are variable.

Compression delay is a variable delay and depends upon the sizes of the packets being compressed. Typically, over slower links, you can choose to compress either the packet headers or the entire payload. Doing either introduces some delay due to additional CPU processing needed to perform the compression.

Codec is a term derived from the function it performs - COmpression and DECompression. A codec is simply an algorithm applied to audio or video streams to make them smaller and easier to transport. Codec delay will depend upon the particular codec (video or audio) that is in use. For voice (VoIP), the most common is the G.729 codec. It is composed of a 5 ms processing time to encode an analog voice stream into digital form and a 5 ms look-ahead time. Look-ahead is used to determine the next several bits of voice to encode (in other words, the codec is predictive). With that in mind, the minimum delay when using the G.729 voice codec will be 10ms. Although it is not network-affecting, there is another type of delay with voice streams: a de-jitter buffer. I won’t go into a lot of detail but basically, the de-jitter buffer stores about 40 milliseconds worth of audio to make up for jitter so the conversation you hear is delayed by about 40 milliseconds. See the jitter section below for more information.

Network delay occurs when a packet is transiting through a network. There is no easy way to calculate it since it varies greatly and is dependent on the makeup of a particular network. You might be able to calculate some delay using the formulas for propagation delay, serialization delay, and forwarding delay but you’d need a pretty good understanding of the network.

Shaping delay is introduced by traffic shaping. You may wonder why an engineer would want to purposely introduce delay into a network. There are times when you need to use traffic shaping. For example, if you have a T1 connection to an Internet Service Provider but you’re only allowed to use half of the speed. Since you’re only allowed to use half of the T1, or about 750 Kilobits, what happens to the remaining bandwidth? After all, a T1 interface card (and any other interface card for that matter) can only transmit at full speed. To solve the problem of transmitting data half the time, traffic shaping is used. It literally transmits data at intervals so that the interface appears to be using less than the full bandwidth. To do this, traffic shaping introduces some delay so that it can divide the data to be transmitted into intervals. I’ll discuss traffic shaping in more depth in a later article.

Forwarding delay is the time between a packet being fully received and when it is placed on an output queue. This delay does not include the time the packet spends in the output queue but it does include the time it takes for the router to route (forward) the packet.

Queuing delay occurs when packets must wait for other packets to be sent. This type of delay is the delay most people think of when they think of QOS. Queuing delay occurs more often on output queues since input queues are rarely congested. There’s no set formula to calculate queuing delay but since it mostly affects output queues, you can use the formula for serialization delay to get a ballpark.

Serialization delay is simply the amount of time is takes for the physical interface to put the bits on the wire and is easily calculated. Simply use the number of bits sent and divide that by the link speed (# bits sent / link speed). So if you wanted to send a 500 byte packet over an old 56K modem, you’d divide 40,000 bits (500 bytes) by 56,000, with the result being about 71.4ms of serialization delay. In comparison, serializing a 1500 byte (12,000 bit) packet on to a 100 Megabit Fast Ethernet link (12,000 / 100,000,000) takes about .12 ms.

Propagation delay is the amount of time it takes for a single bit to cross from one end of a link to the other end and can be calculated with two different formulas. One will be used for the speed of light in a vacuum and the other is a more commonly accepted formula for copper and optical media. The formula used is (Length of Link in meters / 3.0 x 10^8 meters/second). This formula is used for the speed of light in a vacuum. The more common formula used for copper and optical cabling (neither of which exist in a vacuum) is (Length of Link in meters / 2.1 x 10^8 meters / second). As an example, if you had a 100 meter link (the maximum you can have for an Ethernet run), the propagation delay would be 100 / (2.1 x 10^8) or .48 microseconds. One important point to remember is that propagation delay is not affected by the speed of the physical interface so a 10 megabit connection over fiber will have no more or less propagation delay than a 1 gigabit connection over the same span.

Jitter

Jitter is nothing more than an uneven arrival of packets. That is, if you have three packets transiting a network and the first two arrive 10 ms apart but the third arrives 20 ms after the second, you’ve experienced jitter. If all three packets had arrived with an even 10 ms delay between them, that traffic pattern would be called isochronous traffic. Like packet loss, jitter isn’t particularly a problem for bulk data traffic but can be detrimental to voice and video streams. With voice, you hear stuttered speech, hard to understand speech, and can get dropped calls. Fortunately, most voice codecs have a feature to cope with some jitter called a look-ahead. I described this in the previous section about delay.

Bandwidth

Bandwidth is the last and most interesting characteristic in your network. In fact, most of the problems with packet loss, delay, and jitter can simply be solved by adding more bandwidth! Notice I said “most” and not “all”.  Problems experienced in your service provider’s network are a little more difficult to fix by adding more bandwidth since it is highly unlikely that you can get them to add more bandwidth in their network at your request. Problems such as serialization delay can be minimized when more bandwidth is added since a higher throughput interface takes less time to serialize packets and jitter is less likely to occur in a higher speed network.

Planning for QOS

Don’t think you can fix all your network problems by throwing more bandwidth at them. While it does fix many problems, it can get costly. Reflecting back on our grocery store analogy earlier, what if the grocery store had eight checkout lanes and they were all manned by a cashier? You would of course have no wait to checkout but at a very high cost to the store, a cost they’d likely pass on to you the customer. This would make no sense at all. In order to find a good balance between line length and cashier count, you would need to plan ahead. The same is true for networks.

The Cisco way of planning for QOS involves three steps:

1. Identify traffic and its requirements
2. Divide traffic into classes
3. Define QOS policies for each class

These steps make sense when you begin to think about them.

In order to even know what QOS tools to use, you first need to know what traffic is on your network. After you’ve identified it, you need to place a value on each traffic type. If you have an external website serving e-commerce traffic, that will have a higher value than email traffic which will have a higher value than bulk web browsing.

After you’ve placed a value on your different traffic types, you can classify them. This should fairly easily fall into place and should coincide with traffic requirements.

Your QOS policies should result in something like this: e-commerce has the highest priority and should get the most available bandwidth and guaranteed delivery. Email traffic is important but can be one class below e-commerce. It should get 20% of available bandwidth. Bulk traffic such as web browsing, instant messaging, and file transfers is not very important and should get the remaining available bandwidth. It can be dropped if it causes any congestion.

Conclusion

Whew! I know this was a long introduction but hopefully it piqued your interest. As you have seen, the world of QOS is more than simply deciding which packet goes next. It takes knowledge of your network, significant planning, and continual re-evaluation to effectively deploy QOS to a network. Next time we’ll get into traffic classification and marking and discuss a few of the QOS tools that are available.

Enjoy!