Wednesday, November 07, 2007

There is no economic basis for QoS

This was the outline of a paper I planned to write, but for which I just have too little time to get it finished. My main point is that QoS mechanisms in a network are a bad idea (tm) This is generally examined from a technical point of view. The arguments are either generally that we tried it and it didn't work. There is little research on that evaluates the economical side. The little research that there is, generally argues that QoS mechanisms could work if all parties in a communication chain just work together and the reason they don't is because of the lack of incentives. I belief there are several reasons why QoS can't work and why it is a failure of logic.

Introduction

The internet is broken, so we’re told by scientists and standardization bodies. We need a new internet and research at Stanford, Berkeley, Fraunhofer Institute and various European Union programs will fix it. One of the main points of criticism is the internet’s lack of Quality of Service mechanisms to shape and prioritize traffic and to make sure that unimportant traffic doesn’t hurt unimportant traffic. All this in order to give the end-user an optimal Quality of Experience. The ITU has made end-to-end Quality of Service a central element of the design of its specifications for a Next Generation Network.

There is a great deal of attention in academic research on telecommunications networks for Quality of Service mechanisms. It is often stated that without such mechanisms telecommunications networks will not be able to deliver a stable and reliable service. Both from the technical side as from the economical side there is a considerable body of literature on how these mechanisms will work out in the network and in the business models that sustain the network. In order to realize QoS we invest large sums of money in research programs to fix the dreaded problem. Given the amount of scientific papers and research proposals mentioning the absense of QoS as a major problem for the roll-out of all kinds of advanced and mission critical services, how could we not. Everybody says it's important, so it must be important. Except for one minor detail, despite over twenty years of research and various standards and implementations of standards, nobody is using it.

The idea of QoS mechanisms as being essential to the stability and reliability of the network has been at the heart of the Net Neutrality debate. It also rears it head in debates on how to make a sustainable investment in networks and services. The notion of QoS mechanisms has therefore passed the realm of the purely technical and academic and entered policy debates, where policy makers will have to value the various claims.

This paper will examine in a multidisciplinary way the basis for QoS-mechanisms in telecommunications networks from both a network engineering as an economical point of view. Quality of Experience for the end-user is the end-goal of any network architecture and that is where QoS-mechanisms are supposed to deliver. We will show that the use of QoS-mechanisms to deliver QoE is bound to result in failure right from the start, since QoS through shaping and prioritizing is a logically and conceptually flawed concept. It’s a holy grail and a pipedream. These mechanisms cannot work and therefore building either networks, business models or policy on it will result in failure. There is however a simple solution to QoS-problems and that is to over-engineer the network and all the active equipment (servers, routers etc)

What is Quality of Service and Quality of Experience?

Just look it up on the wikipedia. Also look up jitter and lag etc.


What kind of QoS mechanisms are there?

These mechanisms in general take three forms:

- Prioritizing systems, that let packets move ahead of the que based on how high their priority bit is. (like sirens and lights on an ambulance)

- Bandwidth Reservation systems, that guarantee a certain amount of bandwidth over (part of) a link between two points. (like the telephone network that reserved a line between two points)

- QoS enabled routing systems: Routing systems that try to route traffic on knowledge of the state of the network. (like a driver learning of a traffic jam on the route to work and therefore taking another route).

These systems have seen various implementations and all have failed. There are alot of explanations in literature that explain why QoS is not a success. They can be divided into three different classes:

- it's failure of the previous technology, but we will think up a new one that will get it right

- it's failure of economy, bandwidth is too cheap, implementation is too hard (but this will all change, just you wait and see.)

- it's failure of timing, currently we don't need it, because nobody uses the internet for business critical stuff, but the status quo has to change or we cannot do telesurgery etc.


There is very little literature available on whether QoS is actually necessary and whether QoS is actually possible. If all these mechanisms have any chance of working at all.

Many engineers that design the protocols and networks that have build the internet explicitely and implicitely accept that QoS-mechanisms will not work in actual networks. Most sensible engineers don't even want to get into a debate anymore about it.


Actual implementations of Quality of Service Mechanisms

There are currently several QoS mechanisms standardized for use with the Internet protocol.

Diffserv, Intserv, RSVP, MPLS


Categorisering

The conceptual errors that underlie the failure in implementation of Qos mechanisms can be either technical or economical. Technical errors are those errors that make it impossible to design a technical system that answers to all the demands of a QoS-mechanism for it to be technically functional, stable and reliable. Economical errors are those errors that make it impossible to properly implement and operate a network with QoS-mechanisms. The economical errors and technical errors feed into eachother, strengthening each others effects.


Technical errors:

  • Scarcity in the network is a layer 1 problem. QoS mechanisms are operating in layer 2 to 7. We’re trying to stuff more bits into a pipe than can properly fit. Like trying to put marbles through a funnel. Or put differently, trying to fix a layer 1 problem in layer two or three, by making assumptions on layer 7 traffic and on the real world making use of it.

  • QoS routing is NP hard

  • QoS tries to make the pipe more efficient to allow for more traffic. This only works when the pipe is almost full, but not when it’s fully full. In a dynamic system the difference between empty, almost full and fully full is a couple of percentage points. This leaves very little room to manoeuvre

  • QoS prioritization works on the switches that are in between the two users. On a modern system the time advantage that can be achieved by prioritizing a packet through a switch is x millionth of a second. This is less than x% of the one way time of a route of 100km. We’re trying to solve the lines problem in the switch.

  • Qos only works if the switches can derive an order in which to treat applications. If all streams have top-priority there is no way to determine which ones should get priority over other ones.

  • Bandwidth reservation mechanisms are binary. There is capacity that can be reserved, or there is no capacity that can be reserved. This regardless of whether there is capacity available.

  • It may be a straw that breaks the camels back, but there is a lot more weight wearing it down. Removing the straw or one other object might save the back, but the camel remains heavily burdened. Same in networks. Both big and small flows can break a network. It’s the total that counts.


Economical errors:

  • A QoS system will have to weigh the demands of all users in order to weigh the highest utility for all. This will require an insight into the utility function of each user and an overarching utility function to weigh the utilities of all users against each other.

  • There is an implicit assumption that both sender and receiver will value a stream equally high. In any communication, there are senders and receivers. Both have a value for that communication and a value for other communications flows on the same connection. When watching a movie online, the company that broadcasts the movie values the QoE of its customer very highly. It doesn't want the customer to receive a jagged and jittery movie. The customer however is not only watching a movie, but might also be expecting an important phone call or communicating otherwise.

  • QoS works in a static setting (see technical). However the market is dynamic if its healthy. This will reflect itself in the network as one the main platforms over which market forces exert themselves. One cannot assume a static situation for a QoS mechanism if the data flows will follow market dynamics and grow with growth in population and prosperity (when bandwidth usage decreases, there is no need for QoS mechanisms)

  • (variation on above) If market is stable (no growth or declining) there is no reason to ration traffic. If traffic is declining the use of QoS mechanisms after a while is unnescessary. if it is growing than after a foreseeable period there is too much traffic for QoS mechanisms to add QoE.
  • In many business cases surrounding QoS mechanisms there is an assumption that QoS enabled traffic that has been paid for, has a higher value to the user than data that has not been paid for. This sounds logical from an economical point of view if money is an adequate proxy. However it isn’t. Compare a VoIP call that clashes with a pay per view movie. If the VoIP call is about an important subject (birth of child) than it has priority for the receiver, regardless of the QoS level paid for.

Solution
Overengineer the network, so you don't have a situation where QoS mechanisms are appropriate
On end-user connections let the end-user prioritize the traffic to and from him/her. It's the only one that has an accurate view of its utillity function.




9 comments:

Jeremy Penston said...

Hello mate - interesting post!

My take on it is that to a large extent I agree with you, but only when you are talking about "positive QoS", ie accelerating a small subset of the total traffic.

I think what we have seen recently with traffic shaping is a form of "negative QoS" where for whatever reason the people who pay for the network decide to block, slow or defer certain types of traffic.

As much as idealistically, this may be troubling, it is probably necessary because there is a niche of user that will use *as much as they can* without paying for it, because they can.

Is it right that other users should subsidise that niche? Or is it right that the ISP takes a loss because of that niche? No and no, in my humble opinion...

The open network with all you can eat pricing breaks the value equation that we all make when using a finite resource - is what I am going to do worth what I have to pay for it. Without that value equation we get gluttony and as we know that is one of the seven deadly sins...

Don't you think we should all have some consideration for whether it really is worth it to us to do X, Y or Z?

CraigW said...

I am very much in agreement with your technical criticisms. My feelings about QoS detail with traffic necessity, not network neutrality (an entirely different snotbal). Your comment:

>On end-user connections let the end-user prioritize the traffic to and from him/her.

Is easier said than done. Traffic from the end-user is easily handled, but there is currently no mechanism for an end-user to tell the provider how to behave.

I've successfully used shaping to apply back-pressure towards the provider, leaving a fixed chunk of PE-to-CE bandwidth available for use by high priority communications (as defined by the user). But, shaping only works on well-behaved TCP traffic, and it's hardly an iron-clad guarantee.

What is needed is a CE-PE signaling mechanism like uPNP. When a VoIP phone call is made or received, the VoIP software should be able to send a message telling the provider to prioritize that flow on the PE-to-CE link. The provider's mechanism would need to be simple (i.e., not RSVP). I'm thinking a single priority queue that will carry traffic matching a single five-tuple flow.

Colin said...

Hi Rudolf,


You have two main arguments, both flawed:
- It was not succesfull
- it is conceptual flawed (both technical and economical)

First of all, QoS mechanisms (such as Diffserv, RSVP, MPLS and others)is used today at quite a large scale for VoIP, IPTV etc.

Let me dissect the economical error argument.

In the last 15 years or so, we have seen Internet Access penetration rise from nearly 0% to almost 100% This growing number of subscribers required continued network expansion anyway. Second, the bandwidth consumption grew at a very steady state; a simple metric every so many months traffic doubled. Thirdly, the cost per bit dropped at a faster rate than the data traffic growth rate (capacity not per bit transported those costs dropped even faster). So the most effective way was to increase capacity, in fact new subscibers funded the continuous network expansion.

User growth stalled due to saturation. But network traffic growth is accelerating (there is some great insights from Cisco VNI and Sandvine in their recent report) the exact growth rate is uncertain at the meoment. However, this is driven by new type op applications such as streaming media, IPTV/Internet TV, cloud services. No argument that these services are here and used by a growing number of users. Yet, the decline in prices does not keep track with this growing demand. So, expect network providers looking for other ways to ' monetize' traffic. And QoS mechanisms are part of it. In fact the technical shortcomings of QoS mechnisms (static, overhed, etc)are addressed and there are already dynamic systems in development.Deployment will indeed prove to be difficult and hard. But now there is motivation that did not exit before (if anything this motivation is the crucial factor that QoS will be pushed forward depite deployment obstacles).

In mobile networks, especially access (spectrum) is a very limited resource. There is only so much, limited by what ever spectrum is available/licensed and in which bands(not like wireline were you could deploy more or faster access lines). Solutions in the past were deploying more atenna'sbase stations and new radio technologies (GPRS -> HSPA -> LTE). So far this was sufficient to coupe with the growth of traffic. But new sites and new radio technology ar vry expensive (esp when compared to wireline). So mobile operators are much more challanged and willing/motivated to deploy all sorts of QoS (not just round-trip delay, jitter addressing mechnisms; but throughput and accounting addressing mechanisms.
You state that QoS is flawed because it has to take into ccount the needs of al users and that there is very small margin between ' normal throughput' and overload (which is true) but on radio networks these margins are not static and predictable without additional measures (call them QoS/QoE).
If every user has to have a fair change of acces, generating data traffic and accessing content and applications than the 'net neutrality' debate is real and important.

So the recap:
- QoS is alreay deployed
- Economics are changing
- QoS is not a technical problem but a deployment challange

In your conclusions you state:"On end-user connections let the end-user prioritize the traffic to and from him/her. It's the only one that has an accurate view of its utillity function.". Striking that after you call QoS conceptually flawed your recommendation is just that support QoS. Because the only way that recommendation can work is when it is supported thorughout the network (priority has to be signaled throughout the network-or at least along the path) in fact because all end-users can prioritize traffic to and from the network needs to mediate between these demands - surely sounds a lot like QoE management ( and hence requires some QoS).

Colin said...

Hi Rudolf,


You have two main arguments, both flawed:
- It was not succesfull
- it is conceptual flawed (both technical and economical)

First of all, QoS mechanisms (such as Diffserv, RSVP, MPLS and others)is used today at quite a large scale for VoIP, IPTV etc.

Let me dissect the economical error argument.

In the last 15 years or so, we have seen Internet Access penetration rise from nearly 0% to almost 100% This growing number of subscribers required continued network expansion anyway. Second, the bandwidth consumption grew at a very steady state; a simple metric every so many months traffic doubled. Thirdly, the cost per bit dropped at a faster rate than the data traffic growth rate (capacity not per bit transported those costs dropped even faster). So the most effective way was to increase capacity, in fact new subscibers funded the continuous network expansion.

User growth stalled due to saturation. But network traffic growth is accelerating (there is some great insights from Cisco VNI and Sandvine in their recent report) the exact growth rate is uncertain at the meoment. However, this is driven by new type op applications such as streaming media, IPTV/Internet TV, cloud services. No argument that these services are here and used by a growing number of users. Yet, the decline in prices does not keep track with this growing demand. So, expect network providers looking for other ways to ' monetize' traffic. And QoS mechanisms are part of it. In fact the technical shortcomings of QoS mechnisms (static, overhed, etc)are addressed and there are already dynamic systems in development.Deployment will indeed prove to be difficult and hard. But now there is motivation that did not exit before (if anything this motivation is the crucial factor that QoS will be pushed forward depite deployment obstacles).

In mobile networks, especially access (spectrum) is a very limited resource. There is only so much, limited by what ever spectrum is available/licensed and in which bands(not like wireline were you could deploy more or faster access lines). Solutions in the past were deploying more atenna'sbase stations and new radio technologies (GPRS -> HSPA -> LTE). So far this was sufficient to coupe with the growth of traffic. But new sites and new radio technology ar vry expensive (esp when compared to wireline). So mobile operators are much more challanged and willing/motivated to deploy all sorts of QoS (not just round-trip delay, jitter addressing mechnisms; but throughput and accounting addressing mechanisms.
You state that QoS is flawed because it has to take into ccount the needs of al users and that there is very small margin between ' normal throughput' and overload (which is true) but on radio networks these margins are not static and predictable without additional measures (call them QoS/QoE).
If every user has to have a fair change of acces, generating data traffic and accessing content and applications than the 'net neutrality' debate is real and important.

So the recap:
- QoS is alreay deployed
- Economics are changing
- QoS is not a technical problem but a deployment challange

In your conclusions you state:"On end-user connections let the end-user prioritize the traffic to and from him/her. It's the only one that has an accurate view of its utillity function.". Striking that after you call QoS conceptually flawed your recommendation is just that support QoS. Because the only way that recommendation can work is when it is supported thorughout the network (priority has to be signaled throughout the network-or at least along the path) in fact because all end-users can prioritize traffic to and from the network needs to mediate between these demands - surely sounds a lot like QoE management ( and hence requires some QoS).

Colin said...

Hi Rudolf,


You have two main arguments, both flawed:
- It was not succesfull
- it is conceptual flawed (both technical and economical)

First of all, QoS mechanisms (such as Diffserv, RSVP, MPLS and others)is used today at quite a large scale for VoIP, IPTV etc.

Let me dissect the economical error argument.

In the last 15 years or so, we have seen Internet Access penetration rise from nearly 0% to almost 100% This growing number of subscribers required continued network expansion anyway. Second, the bandwidth consumption grew at a very steady state; a simple metric every so many months traffic doubled. Thirdly, the cost per bit dropped at a faster rate than the data traffic growth rate (capacity not per bit transported those costs dropped even faster). So the most effective way was to increase capacity, in fact new subscibers funded the continuous network expansion.

User growth stalled due to saturation. But network traffic growth is accelerating (there is some great insights from Cisco VNI and Sandvine in their recent report) the exact growth rate is uncertain at the meoment. However, this is driven by new type op applications such as streaming media, IPTV/Internet TV, cloud services. No argument that these services are here and used by a growing number of users. Yet, the decline in prices does not keep track with this growing demand. So, expect network providers looking for other ways to ' monetize' traffic. And QoS mechanisms are part of it. In fact the technical shortcomings of QoS mechnisms (static, overhed, etc)are addressed and there are already dynamic systems in development.Deployment will indeed prove to be difficult and hard. But now there is motivation that did not exit before (if anything this motivation is the crucial factor that QoS will be pushed forward depite deployment obstacles).

In mobile networks, especially access (spectrum) is a very limited resource. There is only so much, limited by what ever spectrum is available/licensed and in which bands(not like wireline were you could deploy more or faster access lines). Solutions in the past were deploying more atenna'sbase stations and new radio technologies (GPRS -> HSPA -> LTE). So far this was sufficient to coupe with the growth of traffic. But new sites and new radio technology ar vry expensive (esp when compared to wireline). So mobile operators are much more challanged and willing/motivated to deploy all sorts of QoS (not just round-trip delay, jitter addressing mechnisms; but throughput and accounting addressing mechanisms.
You state that QoS is flawed because it has to take into ccount the needs of al users and that there is very small margin between ' normal throughput' and overload (which is true) but on radio networks these margins are not static and predictable without additional measures (call them QoS/QoE).
If every user has to have a fair change of acces, generating data traffic and accessing content and applications than the 'net neutrality' debate is real and important.

So the recap:
- QoS is alreay deployed
- Economics are changing
- QoS is not a technical problem but a deployment challange

In your conclusions you state:"On end-user connections let the end-user prioritize the traffic to and from him/her. It's the only one that has an accurate view of its utillity function.". Striking that after you call QoS conceptually flawed your recommendation is just that support QoS. Because the only way that recommendation can work is when it is supported thorughout the network (priority has to be signaled throughout the network-or at least along the path) in fact because all end-users can prioritize traffic to and from the network needs to mediate between these demands - surely sounds a lot like QoE management ( and hence requires some QoS).

Colin said...

Hi Rudolf,


You have two main arguments, both flawed:
- It was not succesfull
- it is conceptual flawed (both technical and economical)

First of all, QoS mechanisms (such as Diffserv, RSVP, MPLS and others)is used today at quite a large scale for VoIP, IPTV etc.

Let me dissect the economical error argument.

In the last 15 years or so, we have seen Internet Access penetration rise from nearly 0% to almost 100% This growing number of subscribers required continued network expansion anyway. Second, the bandwidth consumption grew at a very steady state; a simple metric every so many months traffic doubled. Thirdly, the cost per bit dropped at a faster rate than the data traffic growth rate (capacity not per bit transported those costs dropped even faster). So the most effective way was to increase capacity, in fact new subscibers funded the continuous network expansion.

User growth stalled due to saturation. But network traffic growth is accelerating (there is some great insights from Cisco VNI and Sandvine in their recent report) the exact growth rate is uncertain at the meoment. However, this is driven by new type op applications such as streaming media, IPTV/Internet TV, cloud services. No argument that these services are here and used by a growing number of users. Yet, the decline in prices does not keep track with this growing demand. So, expect network providers looking for other ways to ' monetize' traffic. And QoS mechanisms are part of it. In fact the technical shortcomings of QoS mechnisms (static, overhed, etc)are addressed and there are already dynamic systems in development.Deployment will indeed prove to be difficult and hard. But now there is motivation that did not exit before (if anything this motivation is the crucial factor that QoS will be pushed forward depite deployment obstacles).

In mobile networks, especially access (spectrum) is a very limited resource. There is only so much, limited by what ever spectrum is available/licensed and in which bands(not like wireline were you could deploy more or faster access lines). Solutions in the past were deploying more atenna'sbase stations and new radio technologies (GPRS -> HSPA -> LTE). So far this was sufficient to coupe with the growth of traffic. But new sites and new radio technology ar vry expensive (esp when compared to wireline). So mobile operators are much more challanged and willing/motivated to deploy all sorts of QoS (not just round-trip delay, jitter addressing mechnisms; but throughput and accounting addressing mechanisms.
You state that QoS is flawed because it has to take into ccount the needs of al users and that there is very small margin between ' normal throughput' and overload (which is true) but on radio networks these margins are not static and predictable without additional measures (call them QoS/QoE).
If every user has to have a fair change of acces, generating data traffic and accessing content and applications than the 'net neutrality' debate is real and important.

So the recap:
- QoS is alreay deployed
- Economics are changing
- QoS is not a technical problem but a deployment challange

In your conclusions you state:"On end-user connections let the end-user prioritize the traffic to and from him/her. It's the only one that has an accurate view of its utillity function.". Striking that after you call QoS conceptually flawed your recommendation is just that support QoS. Because the only way that recommendation can work is when it is supported thorughout the network (priority has to be signaled throughout the network-or at least along the path) in fact because all end-users can prioritize traffic to and from the network needs to mediate between these demands - surely sounds a lot like QoE management ( and hence requires some QoS).

Colin said...

Hi Rudolf,


You have two main arguments, both flawed:
- It was not succesfull
- it is conceptual flawed (both technical and economical)

First of all, QoS mechanisms (such as Diffserv, RSVP, MPLS and others)is used today at quite a large scale for VoIP, IPTV etc.

Colin said...

Let me dissect the economical error argument.

In the last 15 years or so, we have seen Internet Access penetration rise from nearly 0% to almost 100% This growing number of subscribers required continued network expansion anyway. Second, the bandwidth consumption grew at a very steady state; a simple metric every so many months traffic doubled. Thirdly, the cost per bit dropped at a faster rate than the data traffic growth rate (capacity not per bit transported those costs dropped even faster). So the most effective way was to increase capacity, in fact new subscibers funded the continuous network expansion.

User growth stalled due to saturation. But network traffic growth is accelerating (there is some great insights from Cisco VNI and Sandvine in their recent report) the exact growth rate is uncertain at the meoment. However, this is driven by new type op applications such as streaming media, IPTV/Internet TV, cloud services. No argument that these services are here and used by a growing number of users. Yet, the decline in prices does not keep track with this growing demand. So, expect network providers looking for other ways to ' monetize' traffic. And QoS mechanisms are part of it. In fact the technical shortcomings of QoS mechnisms (static, overhed, etc)are addressed and there are already dynamic systems in development.Deployment will indeed prove to be difficult and hard. But now there is motivation that did not exit before (if anything this motivation is the crucial factor that QoS will be pushed forward depite deployment obstacles).

In mobile networks, especially access (spectrum) is a very limited resource. There is only so much, limited by what ever spectrum is available/licensed and in which bands(not like wireline were you could deploy more or faster access lines). Solutions in the past were deploying more atenna'sbase stations and new radio technologies (GPRS -> HSPA -> LTE). So far this was sufficient to coupe with the growth of traffic. But new sites and new radio technology ar vry expensive (esp when compared to wireline). So mobile operators are much more challanged and willing/motivated to deploy all sorts of QoS (not just round-trip delay, jitter addressing mechnisms; but throughput and accounting addressing mechanisms.
You state that QoS is flawed because it has to take into ccount the needs of al users and that there is very small margin between ' normal throughput' and overload (which is true) but on radio networks these margins are not static and predictable without additional measures (call them QoS/QoE).
If every user has to have a fair change of acces, generating data traffic and accessing content and applications than the 'net neutrality' debate is real and important.

So the recap:
- QoS is alreay deployed
- Economics are changing
- QoS is not a technical problem but a deployment challange

Colin said...

Hi Rudolf,

In your conclusions you state:"On end-user connections let the end-user prioritize the traffic to and from him/her. It's the only one that has an accurate view of its utillity function.". Striking that after you call QoS conceptually flawed your recommendation is just that support QoS. Because the only way that recommendation can work is when it is supported thorughout the network (priority has to be signaled throughout the network-or at least along the path) in fact because all end-users can prioritize traffic to and from the network needs to mediate between these demands - surely sounds a lot like QoE management ( and hence requires some QoS).