DrPeering -

Why hasn’t inter-provider QoS been widely adopted?

Hugh Priorty

----------------------

Hugh -

We asked your question of a few dozen Internet Operators at a North American Network Operators Group (NANOG) meeting. 

Top 10 Reasons why inter-provider QoS hasn’t taken off

First, an academic acknowledged that in the 90’s there were hundreds of QoS papers in academia, and the flow has trickled to nothing. QoS has been described as a “dead topic” The topic has been discussed for over a decade, yet aside from VPNs, we don’t see QoS deployed or discussed for the public Internet.  Why is that?

#1: Bigger Pipes are easier, faster to implement, and less complex

When congestion is reached across a monitored ISP network, ISPs can identify the bottlenecks and simply increase the capacity at these points. No quality of service queuing disciplines need to be defined, negotiated, managed, debugged, etc.

Getting the NOC trained to handle calls associated with a more complex system has costs associated with it.

#2: Chicken and Egg Challenge

A negotiated QoS solution needs to include all possible paths that the traffic may take in order to provide assurances that a constant bit rate will be available between all end points.  Given that there are many thousands of ISPs collectively operating the Internet today, it will take time and be challenging to get buy-in from enough ISPs to make the claim of cross AS guarantees.

#3: QoS doesn’t scale well

It is impossible to guarantee that spot events won’t overwhelm a QoS system.  For example, imagine 1 million end points trying to access an unpredictable combination of 10K content sites. The end result will most likely be a locked up network satisfying a small fraction of the customers that might otherwise be served (albeit served unreliably).  An adaptive application solution in this example would scale  better.

Religious argument: “Core routers should shift bits, not make complicated (per-user:per-flow) QoS decisions.”

#4: I’m not going to hand over the keys to my network traffic engineering to my competitors.

Several concerns here were raised by ISPs:

1) “Bandwidth reservation may break my network.”

2. 2)“Don’t want my competitors to know how my secret (traffic engineering) sauce works.”
   

3. 3)“I don’t want it known that I over subscribe my network, and/or route traffic strategically (circuitously) to meet peering ratios.”
   

Generally, even transparency about treatment of packets in my network is an issue. “It exposes parts of my business practices. For political reasons I may not want the government or broader community to know that.  Competitors may use this information against you. “

#5: Show me the business case that shows that $1 invested in QoS yields more than $1 in profit

Paul Mockepetris said that “QoS is irrelevant in the absence of price”, meaning a QoS business model needs to motivate someone to prioritize packets.

A friend from Stanford said that the Internet in the U.S. is at an economic impasse – “there is no incentive for dollars to flow to where the bottlenecks are.”

There needs to be data demonstrating how much more revenue would be generated by QoS based improvements.

When expressed by last-mile ISPs: “This argument sounds like ‘my last mile business model sucks, so Content Providers and customers: pay us more to make it not suck.’” said one tier-2 ISP.

The other concern expressed is that with QoS, there is the opportunity to charge both customers and content providers a little bit more. Once you charge a little, it becomes easier to charge a lot for access to this captive customer base. This is one issue at the heart of the net neutrality discussion...

#6: QoS is Packet Prioritization is Anti-Net Neutrality

There is a perception that prioritization of traffic  in any way is anti-net neutrality. However, this is not necessarily the case. 

Is it anti-net neutrality if best-effort and premium services are separated across different fibers? Across different VLANs? How about a soft prioritization that looks and feels like these two ?  Perhaps the excess bandwidth added into the now larger system can be made available to the best-effort service when it is not in use by the high QoS services? Best effort can actually benefit from QoS services.

#7: Difficulty in agreeing on QoS specifics (QoS markings)

This is similar to the chicken and egg problem, but the focus is on the challenge getting all the ISPs in the system to agree on the markings and meanings, and have a framework in place to make sure it all works.

#8: Difficulty in developing trust models between competitors.

What prevents a participant from sending all of its traffic high priority?

What if clever engineers figure a way to manipulate the system:

“Show me a bi-directionally metered Internet peering service and I’ll show you a money machine that will make me money no matter what.”

#9: QoS is only relevant when congestion is encountered along the path.

Qwest used the bandwidth upgrade policy when traffic hit 40% peak usage. Level 3 claims to have never dropped a packet.

“Traffic between ISPs in the core are relatively uncongested.” Almost all people said that the issue, the bottleneck, is at the edge.

To them, inter-provider is not the problem. Markings carried across the whole Internet is not critical.

Does this imply that the only relevant parties for QoS are the last mile providers and the content companies (or the CDNs)?

#10: Paid Peering is working

Paid peering between the last mile and content guys is working today. And, a customer relationship with Comcast for example provides a greater attention to problems in the path.

Summary

So there you have it Hugh - the top ten reasons inter-provider QoS hasn’t taken off.

Dr Peering

DrPeering@DrPeering.net

Notes from the Field:

Definition: Negotiated inter-provider Quality of Service (QoS) is a relationship between two ISPs where they “tag” packets with markings to indicate a handling preferences; the other ISP in the relationship honors these markings by treating them in a pre-defined pre-negotiated manner. This might be accomplished by mechanisms described in RFC2474 (diffserve), “tagging” packets with bits indicating a queuing discipline across organizational boundaries.