SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community

CHANNEL BY TOPICS


QUICK LINKS




Quality of Service Doesn't Justify IMS Walled Gardens
» Return to the Colocation Community Homepage

SIP and Open Standards Featured Article


November 05, 2007

Quality of Service Doesn't Justify IMS Walled Gardens

By Fred Goldstein, ionary Consulting


 
One of the hot buzzwords in telecom these days is IMS, which stands for IP Multimedia Subsystem (News - Alert). It’s a network architecture concept that was created by 3GPP, the 3rd Generation Partnership Project, a committee that standardizes wireless networks. The innards of a wireless telephone network are a complex thing, and IMS didn’t mean much until the idea started leaking out. ETSI (News - Alert), a European standards group, created a wireline framework for it called TISPAN; a group of vendors created IPspheres to further that effort. Every major switch vendor now has to bow down at the temple of IMS or the big carriers won’t talk to them. Magazines and conferences galore address the topic.

 
But that doesn’t answer the question of what IMS is, what it does, or why it’s needed. And that, oddly enough, remains a bit of a mystery, even though it has its own magazine, Web pages, and trade group, the IMS Forum. Its promoters insist that it’s a way to enable carriers to create new “services,” and to extend their networks beyond mobility, and beyond voice.
 
IMS begins with the premise that everything is carried inside the Internet Protocol. That’s fashionable, of course; IP is what the Internet uses and anything that touches it must, by inference, be good too, right? IMS is based around SIP, a very fashionable application-layer protocol that has been picking up a growing share of VoIP traffic. SIP is flexible and extensible, both virtues, though they work against another virtue, multi-vendor interoperability. More and more voice is migrating to IP, as is some video, so standards for such applications should be welcome.
 
IMS describes a way to build IP networks that provide Quality of Service (QoS) capabilities that improve VoIP and multimedia performance. But the main new IMS-based service that everyone seems to talk about is “Fixed-Mobile Convergence (News - Alert)” (FMC), the ability to take a phone call between a landline and wireless network. That’s a pretty small market, one for which non-IMS solutions were demonstrated years ago. IMS, on the other hand, is frightfully complex. If FMC were the only new application, then it would be like swatting a fly with a bazooka.
 
IMS sorts out the components of a VoIP network a bit differently from earlier models, like those which currently power millions of cable telephony lines, VoIP service lines and, behind the scenes, many long distance calls. IMS has many more boxes in its reference model, tied together with many more reference points. Unlike, say, ISDN or Signaling System 7, though, which also have well-defined reference models, IMS doesn’t define the behavior of all of its reference points at the level of detail needed for multi-vendor interoperability. IMS adds complexity to networks, encouraging carriers who use it to buy more hardware, software and especially professional services (something this complex takes real expertise!) from their vendors. Since that has met some resistance, IMS advocates now take to describing existing networks in IMS terms, calling existing VoIP “pre-IMS”, or describing how some existing functions are really, more or less, like IMS components.
 
That, by itself, could be viewed as either useful or silly. Who cares how vendors describe a telephone network? What makes IMS more threatening is how it could be applied by carriers, as a tool to build “walled gardens” of carrier-controlled applications, in lieu of Internet access. Taking control of applications is the goal, but it needs a hook to provide that fig leaf of justification. Behind the promotion of IMS for non-voice applications is the notion that the Internet is no longer really about data transfer or the other “information” applications that it was designed for. The Internet, in this view, is the new television, a medium of audio and video entertainment distribution, and networks should be optimized for that. All else is secondary. “End to end” applications, after all, do not share value with the carriers who merely carry the bits between them. That’s what ATT’s Ed Whitacre was alluding to in his fateful Business Week interview that inflamed the network neutrality debate, not concern about how to price premium service for streaming video.
 
QoS Is An Old Problem
It was suggested by Marx that when history repeats itself, the first time is tragedy, the second time farce. Might IMS be the farce of QoS-enabled networks? Enabling QoS on packet networks is hardly a new idea; it’s just a real challenge in the IP world, one that IMS solves in its own uniquely complex way.
 
In the IMS world, it’s still considered reasonable for QoS to be assigned to a phone call when somebody has dialed a phone number or hit the Send button. But for other applications, IMS advocates often expect to set the QoS by using Deep Packet Inspection, in which the actual application flow will be analyzed within the network. IMS will then determine what resources it should get. And, of course, what to charge: IMS is all about creating billable events. Telephone companies, unlike ISPs, live and die for billable events.
 
I think if DPI had been invented two decades ago, any carrier or ISP who used it was moving into the gray area of wiretapping. Nowadays the FCC (News - Alert) treats it almost everything as “information service”, not common carriage, so all bets are off. With DPI, each user’s application streams can be plucked out of a sea of IP packets, and either assigned a QoS and billed for it, or blocked. Billing can even be more granular, based, for instance, on the price of a transaction. Maybe some unidentified bits can flow over spare capacity, what one DPI evangelist calls “hobo class,” but for QoS to work over IP, capacity has to be tightly managed, so that there is ample capacity for billable services.
 
At a recent industry trade show, IMS advocates took an apocalyptic view of the Internet and the problems they assume it to be facing, and how IMS could solve it. Officers of the IMS Forum (News - Alert) answered my question about the differences between the IMS view of the world and the Internet view. On the Internet, it seems, everything’s allowed unless forbidden; on IMS, is everything forbidden unless allowed? That’s done, they explained, because IMS is based on assuming that network resources are scarce, while the Internet assumes that they are plentiful.
 
To be sure, resources to a battery-powered cell phone are somewhat limited, but that needn’t dictate how the bits can be used. The Internet model is about allowing anyone to create applications, so long as they are able to run over the “best effort” service. IMS keeps control of applications with the network operator, so innovation becomes “mother, may I?”
 
I think back 20 years, to when we were writing the standards for Frame Relay and ATM (Asynchronous Transfer Mode, née Broadband ISDN). The goal was to offer QoS options in common carrier networks. FR wasn’t primarily intended to carry voice but with its CIR (Committed Information Rate), it could and did. ATM was intended from day one to work for voice, video and data, both to replace both phone lines and to compete with cable TV, so it had lots of QoS options. None of this involved looking inside the payload — that was strictly verboten, at least in the U.S., at the time. These were considered “bearer services”; the subscriber was expected to use connection-signaling protocols to request QoS options as well as bit rates for each connection. And of course some connections could request “unspecified bit rate” (UBR, sometimes called “best effort”) if that’s all they wanted to pay for.
 
It wasn’t even difficult to create QoS in these networks. They were lightweight connection-oriented networks, meaning that the network kept track of each flow of frames or cells, but didn’t try to perform complex error correction or flow control on them. The network could, however, de-prioritize usage that exceeded the allowable bit rate, and reject requests for more high-QoS resources than it could provision edge-to-edge. Doing this in a connection-oriented protocol is a lot easier than doing it in IP, which is connectionless and thus normally lacks context information. (Later, the IP community developed MPLS, a re-invention of Frame Relay, it is often used in conjunction with IP to provide QoS, especially in enterprise networks.)
 
Why didn’t these services catch on? We first expected Frame Relay to be implemented in ISDN (PSTN) switches, since it was first developed as an ISDN bearer service. But the first product to market just put Frame Relay interfaces in front of a cruddy old PVC-only (permanent virtual circuit) mux, and the first Service to deploy it thus only sold PVCs. That became the model of Frame Relay service copied by other carriers, and of the ATM service that was built out of the products that often also supported Frame Relay. No switched VCs with QoS on demand: No supply, no demand; no demand, no supply.
 
And by then it was 1993 and the Internet was opening up. Connectionless means never having to say who’s paying. No events to bill for save perhaps raw packets, so no handle for QoS-based charging, and no handle for QoS-based services. Common carriage rules for phone companies (below the IP layer) meant that there was wide-open competition among ISPs, who gravitated towards fixed monthly retail rates. The Internet was “good enough” for many things, if not ideal for QoS-hungry apps, and it was very good for the sorts of things that it was meant for. Did I mention its usual flat-rate retail pricing model, without billable events? Americans love flat rates. Cheaper usually trumps better (think Wal-Mart). So everything but the Internet got forgotten, at least from the public and Wall Street perception. (There’s a still ton of ATM and Frame Relay behind the curtains though, all PVCs of course.)
 
But now IMS is trying to take the worst of both worlds, ignoring a problem that was solved 15+ years ago (QoS-enabled switched networks) and trying to come up with something less user-friendly at a higher price. And they’re shameless about it. They don’t think the Internet model of the world is profitable enough. So they use the excuse of QoS to threaten the entire dynamic that has made the Internet, and IP, so successful.
 
This couldn’t possibly catch on if access to Internet Service Providers were still open, but the FCC has revoked the common carrier rules that required telephone companies to sell raw broadband connectivity to anyone willing to pay a tariffed price. The big telcos want to replace broadband Internet access with Fat Wasteband, Broadband Internet’s Evil Twin. And they see IMS as a tool to implement it.
 
To be sure, IMS per se need not be harmful. It could just be used as a tool to develop voice and other multimedia applications in parallel with the Internet. That might even be a good idea. It may be needlessly complex, but those sorts of things tend to straighten themselves out over time. The problem is with how IMS may be used. One of the IMS Forum leaders analogized it to how we Americans view guns — weapons don’t kill people, people with weapons kill people. But he made it clear that he wanted to take aim at the Internet and open fire.
 
The problem isn’t QoS. That can be achieved harmlessly, with or without IMS, even if it turns out to be an expensive luxury. The problem is confusing IMS, QoS, and the Internet. QoS and the Internet don’t go together, and shouldn’t. They’re complementary, but different. Carriers may fantasize of using IMS to build walled gardens, but they’ll never be a substitute for the open innovation of the Internet.
 
-----
Fred Goldstein is principal of Ionary Consulting. He advises companies on technical, regulatory and business issues related to the telecommunications and Internet industries, especially in areas where they overlap.
 


» Return to the Colocation Community Homepage







Technology Marketing Corporation

35 Nutmeg Drive Suite 340, Trumbull, Connecticut 06611 USA
Ph: 800-243-6002, 203-852-6800
Fx: 203-866-3326

General comments: tmc@tmcnet.com.
Comments about this site: webmaster@tmcnet.com.

STAY CURRENT YOUR WAY

© 2017 Technology Marketing Corporation. All rights reserved | Privacy Policy