It’s potpourri Monday, folks, and I’ve saved some items that didn’t make the topical cut last week for treatment. Don’t look for too much of a theme today, other than that I’m looking for “news” that’s not being treated comprehensively.
If you think you’ve heard everything try this one out; the UN’s ITU is proposing a tax on “export bandwidth” from US Internet companies! Sounds crazy, but if you dig down a bit you see the view of many developing countries; that US sites are flooding the networks there with traffic (at the customer’s request, but surely promoted here) and the result is congestion and pressure to spend more on network capacity. Dig even deeper and you run into “bill-and-keep”.
In pretty much every kind of public networking except the Internet, we have always shared the payment for service among the providers who participated. For example, we had (and still do) a notion of “reciprocal compensation” for calls terminating on one carrier and originating on another. The principle is that the terminating carrier is getting socked by traffic and not collecting revenue to compensate. Sound familiar? The problem is that bill-and-keep has become a near-sacred principle for the Internet, enshrined also by Genachowski at the FCC who wants ALL services to move in this direction.
There are benefits to bill-and-keep; the process of settlement among providers is a non-trivial technical effort with non-trivial costs. There are also problems, the most long-standing of which is QoS. Nobody will offer QoS on traffic passing through or terminating on them from another provider who’s been paid for it. But the big point here is that we in the US tend to regard our own system as the baseline, the standard against which all else is judged. It’s an unreasonable attitude, and we need to participate in these debates on the “internationalization” of the Internet in a more enlightened way or we risk losing what we’re trying to protect.
Comverse also made the news, at least the financial news, showing a loss in the OSS/BSS space when many expected the company would gain. There may be a deeper problem in play here, I think. If you look at the “big” application in OSS/BSS it’s billing, and if you look at the issues driving billing you can argue that the big one is the new higher-layer services. In fact, many companies (including Comverse) are seeing changes in services as their big opportunity. The problem is that if you look at OSS/BSS costs relative to the cost for billing OTT customers for their services, you see that the old telco way here is just too heavyweight. That’s true in fact for OSS/BSS in general.
The future of Internet and cloud services isn’t created by evolving traditional voice practices, simply because the technology that creates those services isn’t rooted in the PSTN. There are many who believe that we can simply restructure OSS/BSS, or networking in general, to be able to produce OTT-like services and the telcos automatically win. Not so; all that would buy them is an opportunity to compete, and that won’t turn into a win unless they can offer more for less. What about the old practices, especially in the OSS/BSS space, isn’t really about less for more when you get down to it? We can do voice free, and do, and yet people still want to charge for it. Get a grip. OSS/BSS has to transform. Comverse isn’t transforming it, but neither is anyone else.
Another news item is from the SDN space, where we have a combination of Google’s report that its use of OpenFlow is improving trunk utilization to nearly 100% and one from the ONF itself saying they might let the old earth take a couple of whirls before they update the OpenFlow spec again. Is this illogical? Maybe.
OpenFlow’s big problem right now isn’t as much the state of the standard as it is the context of its application. We live in an under-educated (and maybe uneducable) market, and absent insight from vendors and the media buyers are left to blunder into the truth rather than seek it out. In the SDN and OpenFlow world, that’s true in spades (as it is for the cloud) and so in some ways it might be nice to stop moving the duck while shooters get into position. On the other hand, I’d like to see the ONF become more articulate about those other contextual issues, even if they go beyond the scope of the standards work they contemplate. Should ONF look explicitly at some of the issues Google exposed with its application? Most buyers don’t know what those issues are or how to address them, and yet it’s likely most would hit them at some point in a trial.