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   >   >>
paolo.franzoi 12/5/2012 | 1:24:12 AM
re: Car Pools & QOS
You are correct dreamer that could work, if one were willing to put a headend in the office. Given headend costs, these are generally minimized.

sgan201 12/5/2012 | 1:24:30 AM
re: Car Pools & QOS Hi,
RBOC could deliver broadcast TV in a somewhat similiar and low cost fashion by putting a satellite dish on the CO. The broadcast TV can be deliverred to CO via satellite without massive outlay of the backhaul bandwidth and necessary network upgrade. The expensive CO backhaul bandwidth can then be used to handled VOD stuff. In this model, there is very little difference in the content delivery model between RBOC and the dish people. IN hace, RBOC can even cut a deal with the Satellite TV people.

optoslob 12/5/2012 | 1:24:38 AM
re: Car Pools & QOS Arch,
I fully agree with you from a technical perspective, HOWEVER there are a few additional points that are worth considering.

- If Video over DSL looks like an exact copy of Cable / Satellite than they can leverage the existing Content contracts. If they are even a little different than suddenly they are back at the negotiation table hammering out contracts with every content owner. Keep in mind that these content owners are not very technically inclined, these are the same guys who thought they could kill P2P file sharing by just shutting down Napster. To say they are paranoid concerning technology is a gross understatement.

- RBOC's also want to provide CO based value added functions to the Video. So this will be things like PVR's (TiVo) but as a shared resource within the CO. So if the settop box has no storage capability, than even non real time video needs QOS.


paolo.franzoi 12/5/2012 | 1:24:41 AM
re: Car Pools & QOS
See you miss the point....Cable can become a massive not real time video system by converting spectrum. It can do this anytime it wants.

Instead of taking the analog channels and turning them into digital ones...say turn 1/2 to digital channels and the other half to download content at say 2x DSL rates. Requires new setops but the plant will support it.

By the way, a very small minority own TiVo. They love it but it is a TINY number.

arch_1 12/5/2012 | 1:24:43 AM
re: Car Pools & QOS I asserted that realtime video over DSL is an expensive functional equivalent of Cable TV, and the DSL should instead fulfill the true demand for non-realtime video.
brookseven asks:
Question 1: Is a large channel lineup of real time content important? Well, we have no model for video services that is not that model. If you were the RBOC, would you bet you didn't need one? Would you really bet say $10B?

Question 2: What are these services? Why can cable not offer them? If not real time service is such a good idea, why would cable not do it?

Cable delivers multiple channels of broadcast video because that was what it was technically designed to do, not because that's what people want. In most homes, most of the time, the actual live customer is watching non-realtime video which happened to get delivered over this realtime technology. In a great many cases the customer recorded the material earlier on his TiVo, and is watching it now. for the vast majority of the time, on a vast majority of the channels, the material is pre-recorded at least days prior to transmission, and is therefore non-realtime video.

So I disagree with your characterization of the current cable market. Realtime video technology is used primarily to address a market demand for non-realtime delivery, and it only partially fulfills that demand. The remainder of the demand is fulfilled by video rental and purchase.

What we have is a system that is capable of delivering at most hundreds of realtime channels and which currently delivers less than ten real-time feeds, using the rest of the capacity to deliver an insufficiency of non-realtime feeds.

Why should the DSL industry spend tens of billions to implement an expensive substitute for this inadequate functionality?
Graham Beniston 12/5/2012 | 1:24:44 AM
re: Car Pools & QOS One thing I forgot to mention was the influence of regulation. Our designs for the UK 3 years ago got away with Video on Demand through the B-RAS because fo these issues. BT had to buy DSLAM backhaul bandwidth at the same price it charged to leased line and wholesale customers (DSLAM backhaul is a peculiar term when the asymmetry is firmly in the downstrean direction). This meant that high-percentage simultaneous use of VOD was too expensive, and the solution was to bundle 100 broadcast TV channels. At 5 Mbit/s MPEG-2 per channel this was just about do-able, with IGMP snooping for multicast to the DSLAMs (it did lead to some other interesting ideas, such as a joint satellite/DSL set top box with broadcast channels through the sat. link). So the spec called for limiting the number of simultaneous VOD sessions to 10%.

I do agree with brook seven that raising this percentage above 50% is likely to make the B-RAS at least too expensive if not infeasible. But an interesting discussion would be the effect of moving video traffic off the B-RAS. I don't think this would affect the overall QoS if you kept mulitple ATM PVCs from the DSLAM to the CPE, which I suggested was feasible, practical and cost efficient. The key is to dedicate fixed bandwidth to the PVCs. The idea that you should use the 5, 10 or higher Mbit/s link to the subscriber as "rubber bandwidth" is often not useful, and it is much more pragmatic to reserve a whole 5 Mbit's for video/TV only. The B-RAS wouldn't need to know about it then.
arch_1 12/5/2012 | 1:24:45 AM
re: Car Pools & QOS Tony Li asks:
"Why do we end up arguing over a bunch of arithmetic?"

This is the basic question. I think the arguments occur because we forget to define what we are talking about.

If we restrict ourselves to the last mile (the Home<-->DSLAM link) then ATM v. Packet is important, but only because it affects jitter in the upstream direction.

If we are talking about triple-play DSL, Then we enter a different discussion. I personally think that this is a total loser, unless the vendor can offer a qualitatively different service from Cable. Unless there is a qualitative difference,
DSL will lose to cable.

the only way to win is to offer a new service, different from cable. If the vendor recognizes the difference between true real-time video and non-realtime video, there is an oportunity for diferentiation. Realtime video constitues a very small percentage of the content that people actually watch, but it is the only content that actually requires QoS differentiation. The true killer app is movies on demand. Movies on demand do not requre QoS, since they are not time-sensitive.

If you insist on emphasizing broadcast, you will lose. Cable is perfect for broadcast. Why should DSL attempt to compete with this? DSL should play to its strengths rather than attempting to emulate cable's strengths.

Cable offers a fixed set of broadcast channels, of which a small number are actually real-time. As a consumer, at any given time I want at most one of the real-time channels, OR I want a greatly expanded selection of non-realtime content (movies, etc.) The fact that cable treats thse the same is an artifact of the technology. DSL can win by differentiating real-time and non-realtime content, and offering a vastly expanded suite of non-realtime content. If instead the DSL industry strugles mightly to overcome serious technical obsticles, merely to deliver a functional equivalent of my existing cable service, then it will lose.
paolo.franzoi 12/5/2012 | 1:24:45 AM
re: Car Pools & QOS
The reason is that the consumer gets to make this decision.

Question 1: Is a large channel lineup of real time content important? Well, we have no model for video services that is not that model. If you were the RBOC, would you bet you didn't need one? Would you really bet say $10B?

Question 2: What are these services? Why can cable not offer them? If not real time service is such a good idea, why would cable not do it?

See here is the problem. You are constructing a market concept and saying that your competitor is completely stagnant. He is not.


Tony Li 12/5/2012 | 1:24:45 AM
re: Car Pools & QOS
I think that the decision process for one or two PVC's is actually pretty deterministic. First, it's a function of link speeds, MTU's, and applications.

If there is only one PVC, then the DSLAM and CPE will introduce jitter of at least one MTU's time. Obviously, that time is a function of link speed. If that jitter is unacceptable for the anticipated applications, then you need a second PVC so that your high priority cells can be interleaved or have priority over low priority cells.

Why do we end up arguing over a bunch of arithmetic?

Ben Crosby 12/5/2012 | 1:24:47 AM
re: Car Pools & QOS Graham,

Some good summary there. I'm still not convinced that two PVC's over the DSL link is necessary, but I need to think a little more before I post the details of why not.

I think you'll find some competent folks on this discussion thread who would happily participate in a triple play webinar. Maybe a panel discussion rather than a vendor led one ? ;)

Page 1 / 7   >   >>
Sign In