In talking to someone at a conference recently, I was reminded how much confusion there is around the concepts of “priority” and “importance” in relation to network QoS. He was talking about his “most important application”, and assumed that its packets should automatically be treated with the highest priority. In fact this is often not the best thing to do! In everyday life, “top priority” usually means “do this first” but any good book on time management will tell you to distinguish what’s urgent from what’s important. Given limited time (and what other sort is there?) it’s better to focus on important tasks and ignore trivial ones (like checking email), however pressing they may seem. Likewise when managing QoS on a network link it’s essential to distinguish between packets that shouldn’t be dropped (router updates, for example) from those that need to be forwarded quickly (like VoIP). Some QoS mechanisms only offer only one type of priority, forcing a difficult choice, since using the top priority class for packets that don’t really need urgent forwarding reduces the capacity to handle ones that do (so, less VoIP), but not using it risks losing packets that really need to be transmitted (so, router flap).
A more sophisticated mechanism (such as GoS) allows independent prioritisation with respect to packet loss and queuing delay, so that the QoS needs of different applications can be met without wasting resources. If every application can be given the QoS it needs, then the question of which is actually more important doesn’t arise. Only when there’s a capacity crunch does a choice need to be made, and then the most important application may not be the one needing the lowest packet loss or the shortest delay; but it will be the one whose QoS needs must be satisfied first when deciding how to allocate resources.
Peter Thompson, Chief Scientist
