Network QoS: a losing game

Achieving a reliable quality of service (QoS) mechanism on the networks is a long and unfulfilled dream of network engineers. As circuit-switched networks are becoming a rarity, the concern of bandwidth starvation doesn’t go away, and QoS topic is lively as ever.

Looking at history of the subject, we can make an interesting observation: all attempts at the network QoS are some kind of a failure. It all started when IP, the Internet protocol, was in its infancy and SNA (IBM’s Systems Network Architecture) was looking as respectable business-oriented universal network protocol stack candidate. SNA introduced a concept of class of service back in nineteen-seventies. Search for TERMPRIORITY for details. For example, this one:

Transaction processing priority is equal to the sum of the terminal priority, transaction priority, and operator priority, not exceeding 255.

Amazing idea. It went nowhere.

Internet Protocol was born and raised without QoS. Every now and then people asked – Why my downloads are so slow? Can we really talk online? And (this is really one of the FAQs) – how do I make sure that the boss doesn’t notice that hundreds of other people are using same channel to the Internet?

Implementing QoS was one of the suggested answers. Early on, a byte in the IP header was allocated for TOS, the Type of Service – but its definition is ever-changing. We had a protocol with cool name RSVP. We have diffserv. Microsoft incorporates QoS features in Winsock – this actually helps to solve the boss problem… But network guys aren’ Windows guys so identity awareness is out of question, and application awareness is rather limited: protocols that use dynamic port ranges and those tunneled through HTTP (and perhaps SSL) both are not supported by router-based traffic shaping – the favourite QoS solution. Which is only manageable in point-to-point scenarios and quickly becomes a nightmare as a enterprise network grows.

Meanwhile growth of demand for bandwidth doesn’t seem to slow, and kilobyte a second tends to be cheaper every year. So the real solution to the bandwidth shortage is increasing the capacity of communication channels. Same as it always was. And those dreaming of network QoS may as well use avian carriers for data transmission.

4 thoughts on “Network QoS: a losing game”

  1. The concept of QoS can be summed up as robbing Peter to give to Paul. Bandwidth is finite and all QoS does is to give priority and allocations some and not others.
    One of the things that us networkers have to contend with is chatty protocols. Applications that use chatty protocols don’t see the same amount of benefit from increased bandwidth as others with more efficient protocols. Recently WAN optimization devices help solve these issues as well as bundling in other fancy features such as LIN (Local Instance Networking). Hopefully as time goes by these devices will be more affordable.
    This won’t solve bandwidth problems but would go a long way into making the network pipes more efficient.

  2. As usually an excellent comment. Thanks for reading, more thanks for commenting!

    Those WAN optimisation devices… Do they just fix what the local IP stack does wrong, or there’s more to them?

  3. the analogy “QoS is robbing peter to pay paul” is correct – up to a point.

    Another way of putting it is “QoS is delaying peter’s packet to let paul’s packet go through first”. (The pedantic difference I’m making is that no one was ‘robbed’ – both packets make it to thier destination).

    Remember that some traffic (such as voice) is simply unusable if it gets delayed by more than a few hunder milliseconds. Other traffic (such as reading this web site) does not have that constraint.

    If we want to run synchronous traffic (real-time voice and video) and asynchronous traffic (data) over the same network, then QoS seems to be a good idea – as a concept at least. I think the issue is that the ‘concept’ of QoS never seems to be implemented well enough to get widespread acceptance. That’s why there are so many failures, and seemingly a few more failures happening now.

    (Too much complexity is the common error in my opinion – I see just two classes of packet: synchronous and asynchronous).

    Perhaps IPv6 is when this stuff is finally done right? (Maybe not. I’m starting to wonder, “whatever happened to IPv6?”).

    The _easiest_correct_answer_ is “get more bandwidth”, and that should be OK most of the time.

    The _most_correct_answer_ is “no matter how much bandwidth you have, always send the synchronous packets first”.

Leave a Reply

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