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:

  1. 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.

  2. 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.

  3. 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.

So how did the dual-PVC alternative arise? Supporters of dual PVCs focus on what happens to upstream communication from the customer to the exchange. In a single-PVC scenario, an aggregation device can shape traffic traveling towards the home, but there is no equivalent prioritization of traffic in the opposite direction. Rather than rely on the development of in-home devices with the intelligence to shape the upstream traffic over a single PVC, the "purist" approach uses existing DSLAM support for multiple PVCs, combined with a more sophisticated (replacement) client modem, to allow two-tier, ATM-based, upstream QOS to be reliably achieved.

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.

Page 1 / 7   >   >>
gbennett 12/5/2012 | 1:25:45 AM
re: Car Pools & QOS I've heard a lot of talk from telcos about their plans to deliver video and TV on demand over their DSL networks.

But the backhaul from most DSLAMs is highly over-subscribed - 50:1 in the case of BT here in the UK.

Regardless of any QoS scheme the carriers put in place, there isn't enough bandwidth for video to operate in these networks. VoIP maybe, but not video - even if it is crammed into a 1Mbit/s Media 9 stream!

paolo.franzoi 12/5/2012 | 1:25:45 AM
re: Car Pools & QOS
There is a debate here?

The reason that QoS is an element and is a problem with the TR-58/59 setup is that Video creates the DSLAM as a blocking element of the network. Not just the DSL line itself.

The question becomes how you manage the QoS through the ATM subnetwork to the customer. The claim in the article is that most DSL modems don't support 2 PVCs. Well, they also don't support using Ethernet or IP QoS. That is why for Video over DSL networks its almost always imperative to have interoperability end to end to be confirmed with the vendor set chosen. These systems (all following standards) have lots of issues with QoS management as one factor but there are many others (example: your ISP and your video provider are different).

Anybody thinking that today, any random choosing of Encoder, VoD Server, Middleware, IGMP Router, DSLAM, Modem, and Set Top are going to work is smoking dope. There are specific needs that each element has. There is no reuse of elements (unless one is lucky) from a high speed internet only setup.

That is why there is no debate. Company A solves the problem one way. Company B solves it another way. They all have their plusses and minuses, BUT they are not interchangeable.

gbennett 12/5/2012 | 1:25:45 AM
re: Car Pools & QOS Huw,
Where do you see Ethernet DSLAMs fitting into this picture? I know almost all of the existing base of DSLAMs are on ATM, but a fair chunk of new deployments use Ethernet.

paolo.franzoi 12/5/2012 | 1:25:44 AM
re: Car Pools & QOS
The basic issue is where you place IGMP multicasting points for Broadcast Video and how much unicast traffic you expect to have. If Broadcast dominates, then your need is to transport your broadcast content which can be run over a single GigE for 150 - 200 channels even today.

paolo.franzoi 12/5/2012 | 1:25:44 AM
re: Car Pools & QOS
Biggest issue is what happened to UT Starrcomm at Telmex. The current generation of IP DSLAMs are cost optimized for HSI. They fall down from a bandwidth standpoint once video is applied.

priam 12/5/2012 | 1:25:42 AM
re: Car Pools & QOS With a disclaimer that I don't know what I'm talking about, never having dealt with DSL, but here goes anyway:

I would think that the modem wouldn't have to know about IP priorities, any more than an ethernet PHY does. Rather, whatever presents traffic to it has to so in the right order and with the appropriate preference for discards. So, whatever drives the modem has to do the QOS.

Now one would think passi paru (I always use Latin when I don't know what I'm talking about) that the same would hold for the multiple PVC case,- but presumably the modem is cellifying the data and attaching the (single, canned) ATM header.

Corrections welcome!

The question becomes how you manage the QoS through the ATM subnetwork to the customer. The claim in the article is that most DSL modems don't support 2 PVCs. Well, they also don't support using Ethernet or IP QoS.
Peter Heywood 12/5/2012 | 1:25:41 AM
re: Car Pools & QOS I've been chatting to Graham Beniston about this column.

As some of you will know, Graham has produced a number of webinars and reports on DSL topics, for Heavy Reading, and has taken a keen interest in the DSL Forum's TR59 and its influence on the architecture of next generation broadand networks.

Graham takes an opposing view to Huw - he thinks you do need 2 ATM PVCs - and I've been trying to persuade him to post some of his arguments for thinking this on this message board. No luck so far. He wants to respond with a column of his own, and to do some research before hand.

However, one of the points he was making to me personally was that the issue of 100 million subscribers having to replace their DSL modems in order to support twin ATM PVCs might be a bit of a red herring. The chances are they'd have to buy some other gear anyhow, to be able to use these new types of service, so they might as well buy some gear that incorporated an upgraded DSL modem at the same time.

Someone else also pointed out to me that expecting subscribers to chuck out their old DSL modem isn't as wild as it might seen. Consumers regularly chuck away their cell phones.

gbennett 12/5/2012 | 1:25:41 AM
re: Car Pools & QOS Hi seven,
I understand and agree with what you're saying about one carrier, one broadband architecture.

But surely there's still room for debate? How do carriers decide on these architectures in the first place? There has to be a process of discussion.

It's quite possible that the "first generation" broadband infrastructures that were built over the past few years are now in need of a good shakeup so they can begin to run premium margin applications, such as video and VoIP. In some ways this is good news as there will be a lot of new equipment required, and somebody needs to build and sell it.

But there's a bigger question too - how does the wholesale broadband provider get some revenue from premium applications that run over their network? It's the retail SPs who get that revenue.

Most regulatory regimes of which I'm aware seem to include this retail/wholesale split. (Note, can someone comment on the regulatory situation in Asia/Pac?).

paolo.franzoi 12/5/2012 | 1:25:40 AM
re: Car Pools & QOS
Well Peter,

In the US, Carriers own and replace the DSL Modem. Thus a sub with an existing DSL service and wanted to upgrade it with IP Video over DSL would have to replace that modem (at the carrier expense). There is an entire home wiring issue that has not been part of this discussion yet (i.e. How do we get Ethernet through the house and how do we hook up multiple TVs in different rooms).

I guess my question to you at light reading is why you have never had a webinar with folks that actually have deployed Video over DSL? Skip the equipment companies, go the IOCs that have done it. Theoretical arguments about PVCs are one thing. Getting a router that forwards traffic on 100% of its ports 100% of the time AND can switch channels in a reasonable time AND is cheap (Good number as a toy to use is 100 subs per GiGE - go price out end office router costs with that) is a non-trivial challenge.

paolo.franzoi 12/5/2012 | 1:25:40 AM
re: Car Pools & QOS
It does matter Priam. There are real time requirements on the return path of the set top boxes. If the DSL Modem is not capable of getting that traffic prioritized, customers reach unhappiness.

Page 1 / 7   >   >>
Sign In