Car Pools & QOS
There's a debate going on at the moment about how to make more exciting services, such as high-quality video, available over existing DSL connections. Everyone agrees there's a need for reliable quality of service (QOS) to make these services fly, but the jury's out on how best to use existing ATM-based DSL technology to achieve it.
The core of the debate comes down to how to provision the services and QOS. Some people think there should be two ATM PVCs (permanent virtual circuits – think of them as pipes) to each customer, one for high-QOS traffic and one for other data. Others (like me) think a single-PVC route is the way to go.
So why the debate? To put it in context, a similar debate is raging in the U.K. over what to do about overcrowded highways, which plague many of us who live here. Some want to build toll roads alongside existing highways (multiple PVCs), while others say toll roads will cost too much and take too long to implement – so they propose car-pool lanes as a cheaper, quicker solution (single PVC with IP-QOS). The arguments against car-pool lanes – that they may increase the risk of accidents and will penalize people who must drive alone – have some validity, but the essence of the debate is whether the cheap and quick, if less-than-perfect, solution is better than the more robust one.
This has compelling parallels with the DSL QOS debate: It's a battle between pragmatism and purism.
IP-QOS is important because it allows valuable or time-critical data to be given a "car-pool lane" – or priority over nonessential or non-time-sensitive data. You may ask: "So what?" Well, bear in mind that network equipment is designed to discard small amounts of data if it comes under pressure, and if all traffic on a broadband link has equal priority, then important and unimportant data are equally likely to be thrown away. To overcome this, you need to mandate that streaming video (where discarded packets degrade the quality) has higher priority than Web pages (for which the discarded data can be resent to ensure the page is complete); or TV-grade video (for which a premium is being paid) has higher priority than low-quality video; or a work-related transfer has higher priority than a music download.
The IP-QOS debate surrounds the mechanism for implementing this prioritization. For application developers like me, the outcome of the debate will have a huge bearing on the next phase of broadband evolution.
This debate is a big deal for operators. The telcos currently face something of a dilemma because, despite the optimism that broadband will provide a counterbalance to declining fixed-line voice revenues, the first broadband consumer services (Web access, email, VPN access, all via an ISP) already use price as the main competitive differentiator. These services alone will not revitalize the telco business model. Looking ahead, there's tremendous excitement about the commercial potential of more innovative and exciting broadband services, which will not only appeal to existing customers but will also attract a new wave of broadband subscribers. These novel services form a cornerstone of many operators' forward strategies, so the timing of their arrival is becoming crucial.
This brings us to the "big deal" issue: These services need IP-QOS guarantees, but the vast majority of deployed DSL is not technically capable of supporting it.
To understand why, it's worth taking a moment to look at the DSL link itself. Most PCs make extensive use of the Internet Protocol suite (TCP/IP) to communicate with each other and with the outside world; and in order to support QOS applications, TCP/IP contains information (protocol flags) to prioritize traffic. However, most of the world's DSLAMs (DSL access multiplexers – the equipment at the exchange end of the DSL link) are ATM-based and not "IP aware," so these IP-QOS flags are ignored. This means that all traffic on the link has an equal chance of being discarded – no good at all for the exciting new services that depend on IP-QOS.
In response to this challenge, in September 2003 the DSL Forum published its technical report TR-59: "Architecture Requirements for the Support of QOS-enabled IP Services" contains recommendations for introducing effective IP-QOS capabilities in existing DSL environments. This would eliminate the need for wholesale replacement of deployed exchange and customer premises equipment. From a services perspective, TR-59 is a hugely important document.
TR-59 promotes "hierarchical shaping" as a means to prioritize IP traffic through the DSL portion of the network. The primary TR-59 recommendation is to use a single PVC (one pipe) from an aggregation device via the DSLAM to each residential customer and to shape and prioritize traffic within the PVC using IP-QOS parameters in a "hierarchical shaping" process. The TR-59 also leaves open the possibility of using dual PVCs (two pipes) to each customer, using robust ATM features to separate the "high-priority" from the "best-effort" traffic, as described earlier.
So basically, there are two options in the TR-59, and the carriers must decide which option to take.
To my mind, the dual-PVC scenario presents three significant problems from an applications perspective:
- Most of the 100 million-or-so deployed DSL modems don't support multiple PVCs. Existing DSL customers who wish to use QOS services based on multiple PVCs would need to install a new modem.
- There is a dollar cost for ongoing configuration and operation of each PVC. In a market where applications business cases are marginal, the cost of the second PVC could mean the difference between service viability or failure.
- Dual PVCs dramatically reduce service flexibility. Putting all the available bandwidth in a single PVC allows the resource to be dynamically allocated among multiple services with varying priorities. Splitting the available bandwidth into multiple smaller pipes compromises this capability.
In a purist sense, the dual-PVC lobby has a valid point. After all, we will inevitably need bidirectional QOS, and a single-PVC solution will not today provide the upstream QOS that some applications need. But the pragmatic view accepts that the bulk of near-term residential traffic will be highly asymmetric: Most services will not require robust upstream QOS. If a specific application absolutely requires upstream QOS, it's possible today to offer multiple-PVC capability via an alternative DSL modem, and future modems (or other customer devices) will fit the pragmatic model by providing hierarchical upstream shaping over a single PVC.
My fundamental concern is that the multiple-PVC option should be the exception rather than the rule, because it will inhibit the near-term availability of otherwise viable applications, since many customers won't have the necessary modems to support the technology.
Vendors (via their feature sets) and operators (via their deployment strategies) will determine whether the pragmatic (TR-59 preferred) single-PVC solution will prevail immediately, or whether there will be significant interim adoption of the purist dual-PVC compromise. If the latter is the case, then the combined effect of higher cost, reduced flexibility, and the need to replace most client DSL modems will become a significant barrier to the eagerly awaited next phase of evolution of the broadband services space – a space which is itself the focus of much "commercial viability" scrutiny after the over-optimism which has led to failures in the past.
Back to the car-pool analogy: The pragmatic single-PVC solution has limitations but is cheaper (lower initial and ongoing costs) and quicker to implement (uses existing DSL equipment), while the more robust purist dual-PVC solution is more expensive (equipment and resources) and will take longer (client DSL equipment must be replaced).
In today's economic climate, I believe that pragmatism is usually a better bet than purism. I hope the commercial view of the applications space will prevail, and that the pragmatic single-PVC IP-QOS solution will become the default solution for telcos worldwide… Otherwise, operators risk undermining the service development environment they look to for their salvation.
— Huw Price-Stephens is an independent consultant specializing in broadband service delivery, including network architectures, applications software development, and construction of realistic business models. As the original CTO of Yes Television, his particular area of expertise is IP video. He can be reached at [email protected]
Huw Price-Stephens is hosting a Light Reading Webinar on August 4 – Telco TV: The Opportunity for RBOCs. You may learn more about it or sign up for it here.