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.

Few topics in seem to generate as much furore as “net neutrality”. Lots of factors are at work here, including fear of creeping government interference and suspicion of big business. The latter isn’t helped when two industry titans, in this case Google and Verizon, have “secret” discussions, leading to a set of proposals of what, and how much should be regulated (in the US at any rate). However it’s interesting that any agreement was even possible between these two, given that Google has been a staunch supporter of neutrality, while Verizon, as a service provider, could be expected to favour tiered services. The compromise is an affirmation of non-discrimination for “broadband Internet access” and a requirement of “transparency” on the one hand, while allowing “reasonable network management” and “additional or differentiated services” on the other. An exclusion for wireless access and the caveat of “lawful” applied to content, applications and services have critics such as the EFF hot under the collar, but on the whole this does seem to be a step forward in the debate.

What net neutrality diehards don’t seem to want to acknowledge is that packet networks rely on statistical multiplexing in order to be economical. While a service provider may offer, say, a 20Mbit/s connection to all their subscribers, it’s infeasible to actually deliver packets at that speed to all of them simultaneously. The network relies on the fact that users generally don’t exploit their full bandwidth allocation all the time, in order to be able to deliver it to all users some of the time. When applications such as video streaming and peer-to-peer filesharing break this assumption, something has to give. Insisting on a “right” to run such applications regardless is akin to demanding a “right” to drive a car at its maximum speed all the time; in both cases this disregards the rights of other people using the same infrastructure. We’ve come to accept a system of speed limits on the roads and some equivalent mechanisms for networks are inevitable so that they can continue to function in the face of insatiable demand. Net neutralists need to engage in a debate about what limits are fair and how they are to be enforced, and Google should be applauded for doing just this rather than condemned as evil.

Quality of Service (QoS) has long been regarded in some quarters as rather fiddly, technical, and difficult to relate to everyday concerns. The new buzzword is “quality of experience” (QoE), which sounds, on the face of it, much more intuitive. Who wouldn’t want a good quality of experience from their network service? Obviously this is something that service providers should strive to improve! On closer inspection, however, things are not so simple: a user’s “quality of experience” is fundamentally subjective, so it’s not easy to measure, and in any case depends on many factors that are outside a service provider’s control. For example, you might not enjoy an otherwise excellent video conference session if a lot of the screen pixels were dead, you had a migraine or got fired in the course of it! So “QoE” has come to mean those aspects of the delivery of a service to the end user that it’s possible to measure. This brings it very close to another useful, but less widely used, concept, “quality of application” (QoA), which is the performance of the distributed system delivering the application or service. This is almost the same thing, but looked at from the inside out: an engineering view of service delivery.

So what determines QoA? Let’s start from the user: the first part of the system they interact with is some sort of end-point, whose performance may be inadequate. For instance, we had an issue here with Skype, running on a dedicated but very old laptop that turned out to be underpowered for the job (I believe that the latest versions of Skype check for this sort of problem and give a warning). Replacing the computer with something less antiquated made a huge difference! On the other side of the equation is generally a server, or sometimes several, for example when a webserver needs to query a database in order to display a page. The increasing trend towards centralising servers in data centres has spawned a batch of server monitoring tools to keep track of this critical aspect of QoA.
Finally there’s the network that connects all the endpoints and servers together, whose performance we call “QoS”. QoS is complicated because the network has to do lots of things at once, all of which need to get consistent service (just like a server supporting a bunch of VMs). Not every application needs low latency, but every application needs some bound on the delay and loss its packets will experience when crossing the network or else its QoA will drop, taking QoE with it, and maybe giving you that migraine in the first place, or even getting you fired if it was your job to do something about it!