& cplSiteName &

Can SBC Spark Interest in QOS?

Light Reading
News Analysis
Light Reading
8/27/2002

SBC Communications Inc. announced yesterday that it has joined forces with Sitara Networks Inc. to offer a new quality-of-service solution to its enterprise customers (see SBC Delivers QOS Control).

You heard right: That's QOS, the technology that flared up in the late nineties, then fizzled, as many companies decided it was easier to just add bandwidth to their networks than to regulate it by application.

Now, companies facing reduced capital budgets and bandwidth-intensive applications may be ready to reconsider QOS as a means of squeezing more out of their existing broadband infrastructures.

At least, that's what SBC is counting on. The carrier hasn’t started marketing its enterprise QOS service yet, but Rick King, the company’s executive director for professional and managed services, says a handful of the company’s existing customers have voiced interest in the solution.

While it will be another six to eight weeks before SBC's sales team is ready to push it, King says the technology, which is available now, has been lab-tested and SBC will be “showering attention on the first" deployments.

Here's the plan: When a customer signs up for the service, SBC will first monitor its traffic for two to four weeks, before categorizing the customer applications in three priority buckets: business critical, business important, and best effort. Then it will allocate bandwidth, guaranteeing enough for the business critical applications at all times.

All the customer's traffic will be filtered through Sitara's traffic-shaping and allocation hardware appliances, which SBC will deploy between the WAN router and the LAN equipment on the customer premises. SBC personnel will manage the boxes through the carrier's Application Performance Management (APM) platform. By analyzing the traffic flowing through the Sitara box, SBC will be able to determine how much bandwidth each application uses, and thus set policies to allocate the necessary amount of bandwidth to each application. APM is interoperable with Multiprotocol Label Switching (MPLS).

SBC's using five different off-the-shelf Sitara devices, called QoSWorks boxes, for customer deployments. Each box supports speeds from 384 kbit/s to 100 Mbit/s. According to King, SBC will check bandwidth policies monthly to keep them updated with each customer.

Reaction to the news has been mixed. The rollout certainly represents a big win for Sitara, which says it beat about six other solution providers to the chase, acknowledging it's had no previous contracts with U.S. service providers. A spokesman says Sitara's in talks and trials with other American carriers.

It's still a question whether the announcement will prove significant for either SBC or for QOS.

SBC of course, says it's important. King points out that SBC is the first carrier to offer a QOS solution at the customer premises, which allows filtering by application. Until now, QOS services have centered on using MPLS to guarantee bandwidth to locations, not specific applications.

But at least one analyst says CPE-based QOS solutions may not be long for this world. “Ultimately, the enterprise just wants the service it’s paying for to be reliable,” says analyst Mike Harris of Gartner Inc. He says a solution like SBC's adds complexity to a network. Enterprise users have moved on, he maintains, and they don't want to deal with the headache of having to make sure they have enough bandwidth for key applications. And he thinks service providers will have to start shouldering the burden of controlling QOS from their own facilities, not their customers'.

Harris also wonders where SBC's users are for the new service. “I’m surprised they didn’t have any beta customers,” he says. “But they clearly had a fully fleshed out pricing scheme… The service is well thought out.”

— Eugénie Larson, Reporter, Light Reading
http://www.lightreading.com

(24)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Page 1 / 3   >   >>
gea
gea
12/4/2012 | 9:51:59 PM
re: Can SBC Spark Interest in QOS?
"Ultimately, the enterprise just wants the service itGÇÖs paying for to be reliable"

This is actually an issue we've debated here on the LR pages for a while now. In this case, however, pure "QoS" is not exactly the only issue. I can have very reliable low-priority traffic, and in some places this may be a very attractive thing if the price is right.

As for the argument of "throw bandwidth at the problem", that's only appropriate in certain scenarios. In many metro networks, there is no DWDM. That means a service provider can not simply "slap in another transponder" to add more bandwidth via DWDM. ANd as the cost of adding DWDM to a network that doesn't already have it is very painful, I believe there will certainly be carriers that elect QoS as a way to shift around their costs and offer tiered services while dealying the introduction of DWDM (which is otherwise is an unwanted cost).

In addition, QoS is simply the first building block in a future that will certainly contain packet-based services. Say I'm a company wanting a high quality video conferecing link from here to Kalamazoo that only lasts a few hours. In the future a smart service provider will offer that capability, and they'll need QoS to do it. (The customer might not even be directly exposed to QoS.)

Thus even if SBC doesn't directly make many with this offering, I think they're smart for at least starting to work in this direction. Eventually, there will be just couple of very low-cost commodity bandwidth sellers. Anyone else still in busines will have learned how to offer "value-added" services, and QoS is an essential tool for that.
GlowStick
GlowStick
12/4/2012 | 9:51:59 PM
re: Can SBC Spark Interest in QOS?
I continue to be surprised by analysts' comments that suggest that application sensitive QoS is not very useful while implying that adding bandwidth is easier and cheaper.

One need look no further than an example where the CFO's application needs to execute a critical transaction immediately, yet the network is flooded with realtime video and Napster traffic. All three applications have different bandwidth and QoS requirements; simply adding bandwidth is not always a reasonable solution.

If ratio of non-business critical traffic to business-critical traffic is high, then adding bandwidth will not be cost-effective. It may be that increasing bandwidth by an order of magnitude simply increases the amount of Napster traffic by an order of magnitude as well.

Neither the CFO nor the realtime video application are particularly well served in this scenario, yet the enterprise's access charges have increased substantially. Simple traffic prioritization would be cheaper and more effective. And it might get some music hungry employees back to work...
rjmcmahon
rjmcmahon
12/4/2012 | 9:51:59 PM
re: Can SBC Spark Interest in QOS?
I continue to be surprised by analysts' comments that suggest that application sensitive QoS is not very useful while implying that adding bandwidth is easier and cheaper.
_______________

Think of it this way. Imagine you were paying a general contractor a lot of money to build your home. He in turn hired 20 carpenters to build the framing.

Then the nail supplier calls up and says, "Hey I've got a deal for you. I'll sell you nails which will never break, though at a much higher price, but only the general contractor can afford to use them. The carpenters' nails will only fail some of the time, which doesn't matter anyway, because they are not working but rather are standing around with their headphones on listening to music."

Not too many CEOs will fall for that pitch and the ones that do will be running their employee productivity into the ground.

From an RBOCs perspective where employee productivity is zero and title and status receives taxes regardless of worth, then SBC's QoS pitch would make all the sense in the world.

To any CEO interested in productivity this QoS pitch is a joke.
rjmcmahon
rjmcmahon
12/4/2012 | 9:51:58 PM
re: Can SBC Spark Interest in QOS?
But do you think it still applies as more realtime applications live voice, which are much more sensitive to periodic bursts than napster or mail, become more commonplace over packet networks?
_____________________

I believe the burst arguement is a Red Herring. Those that converge their voice and data networks will expect them both to work. Anybody that bought a DVD player where the video drops out but the audio still worked would take that DVD player back to Walmart for a replacement.

SBC's fundamental goal is to *create* congestion so they can charge access tolls. They are nothing more than a toll bridge operator of our bridges; bridges which have been paid for many time over; bridges that have not been returned to the pulic good as was the original agreement.

An honorable city would condemn these bridges and give them back to the public to whom they belong.
GlowStick
GlowStick
12/4/2012 | 9:51:58 PM
re: Can SBC Spark Interest in QOS?
Good analogy, and I think I understand your point, particularly with respect to today's traffic patterns. But do you think it still applies as more realtime applications live voice, which are much more sensitive to periodic bursts than napster or mail, become more commonplace over packet networks?
sigint
sigint
12/4/2012 | 9:51:52 PM
re: Can SBC Spark Interest in QOS?
How well does the Sitara box handle voice traffic?

Assuming that it does provision enough bandwidth for voice, an additional node delay would be inevitable. What, if any, are the implications for voice quality ?
DoTheMath
DoTheMath
12/4/2012 | 9:51:51 PM
re: Can SBC Spark Interest in QOS?
Quote: Thus even if SBC doesn't directly make many with this offering, I think they're smart for at least starting to work in this direction. Eventually, there will be just couple of very low-cost commodity bandwidth sellers. Anyone else still in busines will have learned how to offer "value-added" services, and QoS is an essential tool for that.

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

I disagree with your last statement. SBC is merely "value-padding" not value adding. Assuming that the enterprise really wanted to prioritize its IP traffic, whatever SBC is attempting to do through this can be done by the enterprise much more cheaply. The Sitara box is not all that expensive, and what prevents an enterprise from putting it in front of their WAN router and shape their own traffic before it hits the bottleneck?

Yes, SBC will "guarantee" that its network will honor thoese QoS priorities. In all IP traffic, how can it guarantee that today?

More fundamentally, the only way out I see for telecom is to offer ultra-cheap bandwidth, cut costs to the bone to run the network, and quit trying to value-padd. Even Airlines are finding "business class" doesn't work anymore - when even Microsoft employees (richest in the world) travel coach.


dudeman
dudeman
12/4/2012 | 9:51:50 PM
re: Can SBC Spark Interest in QOS?
While it makes sense to do QoS, and make sure that the Enterprise customer's business critical traffic is not affected by other categories of applications (doh, I don't run a network for fun...:) ), it definitely is a very poor solution to do it via stand-alone appliance boxes!

--> Stand-alone boxes don't have knowledge of WAN link states, ATM PVC states, etc.

--> They cannot support features such as link fragmentation and interleaving, FRF.12, etc.which are required to do real-time / VoIP on anything less than 768K links/PVCs, in order to reduce the impact of serialization delays!

--> Why put in a box solution (and have to learn another box, manage another box, worry about it failing, etc.) when routers can do QoS very effectively? Cisco routers today, especially at the remote office and aggregation routers, have enough horsepower to support all the features needed. I have experience with 7200 and 3600 series routers in the past, with all the QoS features one could ever dream of :)). The only issue with Cisco in the past was lack of monitoring capability, but they seem to have fixed these issues very aptly by adding a very comprehensive QoS MIB, the Service Assurance Agent and Network Based Application Recognition capability...

-> It doesn't make much sense to have one DiffServ class, so to speak, for each application..wouldn't scale and would be too difficult to manage. What makes definite sense is having four or five application buckets and categorizing the applications into these.

Viva Simple & CommonSense!! Doh!!! :))))))



GlowStick
GlowStick
12/4/2012 | 9:51:46 PM
re: Can SBC Spark Interest in QOS?
--> Stand-alone boxes don't have knowledge of WAN link states, ATM PVC states, etc
---------------
It would seem, according to the marketing blurb from CheckPoint about their QoS product, that having a QoS solution on either side of an firewall is disadvantageous, hence it should be coresident.

Some of the claims seem somewhat dubious at best. Anybody an expert on such things?

And on a slightly different topic, what about countries outside North America and parts of Europe, where bandwidth is not by any stretch in large supply? Can a better business case for QoS be made in these environments?
JustWantToSaySomething
JustWantToSaySomething
12/4/2012 | 9:51:44 PM
re: Can SBC Spark Interest in QOS?
I think its not a bad idea: suppose, you as a company have to rent a DS3 link to your service provider, just because your employees want to listen to music.
With the box in between you and the service provider, you would be able to limit your traffic to DS1. It could save you a lot of monthly fees to the service provider, even taking into account some thousand bucks for the box. So, you as customer would buy, wouldn't you?

jwtss
Page 1 / 3   >   >>
Featured Video
Upcoming Live Events
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events