In his previous posts, Gabe introduced networking's QoS team and touched upon some of the areas we're focused on. Over the next few months, we'll present some of the technologies we've been building. Before we look at these, I'd like to cover some of the existing QoS concepts/standards/mechanisms/technologies. That'll be our base for further discussions.

At its simplest, networking elements treat all packets the same way. The switch in your closet at home treats the packets from your computer the same way as those from your roommate’s computer. The first approach to QoS is to change this: get the network to favor some packets. True, this is not the only meaning of the word QoS but it's what a lot of people think of.

Why do they want this?

• Maybe they want to protect bandwidth for one of their scenarios. Streaming an HDTV show to my Media Center extender takes a lot of bandwidth. If two people in my house trying to do this simultaneously on the same wireless AP, neither one of them is going to have a great experience. There's simply not enough bandwidth.
• Maybe they want to prioritize some operations over others; have them complete faster. For example, accessing a database instantly might be critical to making a sale. On the other hand, it's ok if the database backup takes an hour longer.
• Maybe they want to minimize packet loss for one of their applications. Yes, protocols & codecs can be used to handle packet loss; however, dealing with a loss can be expensive (in delay or data overhead). I'm sure you've had bad phone calls (or Voice-over-IP calls). Why not select ahead of time which packets to drop if one must be dropped?
• Etc.

All of these center around the same theme: all scenarios are not equal.

Going back to this first approach to QoS, you need a few things to get the network to prioritize packets. Here are some of them:

• A way to identify the special packets
• A way to specify what to do with these special packets. Prioritization is only one of many things people wish for.
• A mechanism to implement the prioritization itself 

Let's look at the first item in this list. How does your router know which are the special packets?

• Your network is intelligent enough to analyze packets you send through it and recognize the special one. It's classifying your traffic. This could be as simple as which wire your packets are arriving on a router or as complex as discerning Voice-over-IP traffic from web browsing.
• Your computer, or a device at the edge of your network if you have a large network, “colors” your packets. For example, this “color” could be a few bits set in your IPv4 header. Ideally, your network equipment only needs to looks for the color. 

Each approach has its advantages and disadvantages. The first doesn't require you to fiddle with your computers. But does your router really know more about the traffic your application is sending than your application itself? The second lessens the complexity of your network equipment (in addition to being less CPU intensive for it). But how does your router know if it can trust the color? How do you, the owner of this equipment, prevent abuse? If it was known that purple traffic “goes faster”, wouldn't everyone always use purple?

This brings us to an interesting realization. In this approach, QoS does not make more bandwidth available. It only changes the way existing bandwidth is distributed amongst the consumers.

My follow up entries will look at ways to color traffic. I'll cover how these tie in with Windows. I'll also discuss some of the issues people often are unaware of.

- Mathias