Crafting Requirements for QoS

Quality of service (QoS) is a maker and a breaker for most network engineers. For those new into the field its a confusing out of order mess of syntax to read through, and to a pro its s headache and a nuisance to manage. Now in many big companies in the western world the main goals of QoS is to make sure your voice and conference video maintain their quality and relegate the rest. A network engineer then looks at it and tweaks it occasionally. Normally when they get a call that a phone calls quality wasn’t very good. Unfortunately, when you begin supporting rural areas or third world locations throwing bandwidth at the problem is not always a fiscally viable option. Its important to realize that the only real solution to a congested link is more bandwidth. All QoS allows you to do is pick winners and losers. Now there are many ways to design a QoS structure. I like to start at the front and work my way back. First, define the requirements for the bottleneck which is normally the WAN. Set up the queuing structure and begin working my way back into marking and classifying the traffic.

To know what queuing structure to use good requirements are a must and a solid understanding of what the nature of the traffic is, and the complexity the team is willing to take on. The way I envision the nature of traffic in my head is as a cube. One must weight the latency sensitivity, expansiveness, and the business case for each flow of traffic and make a determination on how to best queue it to maximize performance of the link.

Now latency sensitivity refers to how noticeable packet loss, delayed packets, and jitter have on the users experience. A TCP transaction between two computers is usually seen as not being sensitive.┬áSince TCP retransmits missing packets, and a computer typically doesn’t mind waiting an extra 2 milliseconds its not much of a problem. On the other hand a phone call which uses UDP packets is considered very sensitive. This is because any kind of packet loss and jitter will lead to distortion in the voice of the participants, and because the traffic is UDP and lost packets will not be retransmitted. This is why real time protocol (rtp) is normally at the top of a QoS structure.

The second aspect to consider when profiling your traffic is expansiveness. A audio only call or loading a web page has a very finite amount of bandwidth necessary to have a good experience and will take up more or less the same amount of bandwidth each and every time. On the other hand, streaming a YouTube video will see how much available bandwidth there is and attempt to use as much of it as it can to improve the quality of the stream.

Lastly is the business case. This in some cases is not as clear without talking to fellow employees and understanding their Internet use. One good example of this is YouTube. While there are certainly several videos on there that are just employees wasting time at work, there are also some great instructional and educational videos. So yes you can throttle it completely, but then you cut people off from a source of valuable information.

Ultimately, there is a lot of personal judgment that needs to be made, but there are some best practices that can be followed. We will go into detail on designing your queues in my next post.

Leave a Reply

Your email address will not be published. Required fields are marked *