Ken, this is a long one. So, consider yourself warned. [g]
===
Re: "IP Myth vs. Reality"
From the article, the author makes a statement that current hype would have us believe that:
>...every conceivable information transfer will be over Internet Protocol (IP) by the year 2000 or shortly thereafter.<
Does this include TV, Mainframe Bulk Data Transfers, Cellular...?
My opinion is yes, that the majority of these will, with increasing percentages. This is not mere speculation on my part, as I am watching it unfold every day before my eyes. [[It will take TV a long time, however. Heck, the TV community can't even arrive at consensus on the deployment of HDTV yet, after all of these years.]]
But certainly not by 2000, or even 2005, well maybe by 2004, 2005 we'll see a good part already shifted. We're looking at some very large announced plans for acquisitions and roll outs for next year, which very definitely are NOT Internet- [IP-] based. And these will no doubt need time to depreciate and migrate. At the same time, ATM deployments are up from where they were a year ago, [ even IP Barons Crowe and Nacchio have announced dependencies on it. But this is where the arguments such as these fall apart, because IP and ATM are increasingly not mutually exclusive to each other yet (?) but for the sake of discussion, we'll pretend they are].
While there is integration going on all the time to make these two protocol stacks more conducive to one another, there is absolutely no guarantee that the end game won't look a lot more like today's ATM at that time, than the IP we have come to know today. In fact, if I were a betting man, I'd put my money on a new IP that looked very much like today's ATM.
>IP is cheaper than circuit-switching telephony.<
The medium [lines] become 'apparently' cheaper at first, and later, due to efficiencies and enhanced functionalities fostered by the protocol itself, the paradigm will be cheaper. That's the end game here. But today it depends on when the acquisition is made, what elements we're talking about, and for what purposes, in addition to a host of other factors.
It also has to do with some subjective things like what the tradeoff tolerance level is, vis a vis comparisons to the quality of alternative means, and what religion one happens to subscribe to this month.
>Ever since vocalic [?] announced its IP Telephony Gateway switch in 1996, the telecom world has been abuzz over IP telephony and the enormous potential savings it offers compared to old-fashioned switched telephony. First, there is the savings hype about using the "public" Internet for telephony. Then there is the value-added reality of using a closed user group intranet (i.e., using IP technology for switching or segmented transmission) for IP telephony....The only reasons entrepreneurs make money sending telephony traffic over the public Internet are the savings gained either through avoided settlements and/or access charges. U.S. international carriers that terminate calls in foreign countries pay settlement fees upwards of $1 per minute. Internet Telephony Service Providers (ITSPs) slip originating international calls over the Internet, and terminating Internet Service Providers (ISPs) that complete these calls pay local rates at both ends at a substantially lower cost (a few cents per minute) than international settlement rates. This makes the economics work. Regarding domestic long distance, carriers pay more than 2 cents per minute at each end (originating and terminating), and ITSPs pay business interconnection rates, which are less than 1 cent per minute. <
While some of this is still true, note that the arbitrage really only makes sense on the international side at the current time, and that domestic fees and charges are subject to change, with the whims of those in Washington.
>The FCC allows this settlement/access avoidance by the ITSPs for two reasons. First, the regulators want to sock it to the foreign PTTs which refuse to adjust their international settlement accounting rates to a more cost-based price and, second, they want to avoid the political backlash from requiring consumers to pay measured rates for Internet access.<
True, to a good extent, IMO.
The FCC actually used ITSPs as a hammer last year in their publicly worded message to the PTTs around the globe that if they don't comply to its proposed changes in the accounting rates, that they would lose out in the end, anyway, to Internet Telephony.
The implied message here was that the FCC would favorably sanction ITSPs to go forward... and it also implied at a more fundamental level that they had the power of do or die over the ITSPs. But how much shelf life does this posturing have in the face of other decisions the FCC will be forced to make over the intermediate term? I don't know.
> Besides, voice quality today over the Internet isn't very good due to latency delay, the general inability to transmit touchtone (DTMF) signaling for interactive voice response units after call completion, sound fidelity and more. Furthermore, the FCC doesn't face political or universal service fund problems, except those caused by RBOC and independent telco lobbying.<
As for the voice quality, yes it pretty much still leaves a sucking sound when taken on average. But I think that we can almost plot to a point in time when VoIP will be on a par with traditional 3 KHz switched voice, and then beyond that point, when it will be superior.
As you can probably tell by now, I'm annotating this on the fly. The author obviously agrees with some of what I've stated above. And quality issues are improving, but a lot of this has to do, again, with proper sizing and engineering, not the makeup of the native technology [which is also under constant pressure to change in order to improve itself where there are shortcomings]. The economics of design are (or will increasingly, be) key.
>IP networks are more robust and reliable. <
As compared to what? Today they are not, for they still depend almost exclusively on the Lower Layers they are poised to supplant. Here, as in disaster recovery planning, one must always ask "robust and reliable in the face of what kind of threat?"
>The Department of Defense funded the development of the IP protocol called TCP/IP because it wanted to replace the ARPANET network it funded for university research. TCP/IP would allow for the networking of university research centers and create a platform for highly robust and reliable military networks. The myth was perpetuated that if DOD uses IP networks they must be more robust and reliable than circuit switched-networks! <
And he goes on to develop arguments why it is not. His arguments are valid only to the extent that if the TCP/IP network is not sized properly, and if the wrong -or no- policy rules are implemented, then it will be less dependable than it would be, otherwise.
I will give him, however, that the outgrowth of the public Internet to this point in time has reflected a less than desirable result, from the standpoint of availability, reliability, prioritization, networking reach, response-time and security.
In order to get around these pitfalls, the ISPs really have their work cut out for themselves, IMO. They must begin to use some new tools, and learn some new disciplines, not unlike those which the Telcos have been administering for over a century. They must learn to deal with very large scale universes of users, in a multi-pluralistic set of topographies on several strata, all the while guaranteeing a uniform look and feel at all times.
And in sizing their nets they will find that if they do the other things right, they will in all likelihood need to increase the size of their peering pipes, and upgrade their routers at the same time. This does not bode well for the startup ISP who may be operating on a shoe string, unless they have the cash flow to support growth, or some other means of funding new acquisitions of b/w and other infrastructure.
>They are not! Here's why: The Internet is, in general, a collection of Ethernet LANs and routers riding on the IP protocol platform, TCP/IP. They have the following characteristics: When traffic becomes heavy on LANs, routers or PCs running on TCP/IP, each acts to slow the networks down or close them. An Ethernet is a connectionless packet network. When traffic increases on an Ethernet LAN the packets from multiple terminals begin to collide with each other and have to be retransmitted; therefore, less traffic gets through. When routers are congested, their buffers (packet storage while in transit) fill and newly arriving packets cannot be handled, so they are dropped. Then the routers send more control messages to each other, exacerbating the congested conditions. Finally, TCP/IP sees the packets sent not being acknowledged as received. In response, the originating terminal slows down its packet generation. The way the military solves this problem, simplistically speaking, is by giving the general's terminals higher priority and the private's terminals lower priority. This priority approach would not be satisfactory in a common carrier network environment. <
The author goes on to state that:
>>The reality is that today's circuit-switched and time division multiplexed-based (TDM) private networks are orders of magnitude more reliable than the public Internet and, for that matter, intranets.<<
Again, that depends on the type of traffic that is being protected, and the topologies involved. If I have, say, a private line circuit going to Cairo for the delivery of daily updates of my inventory, and this private line happens to fail anywhere long the path (it could happen in any of dozens of locations), it will likely take me anywhere from several hours to days, or weeks, to get it repaired and resolved to my satisfaction. Anyone who's been there knows what I'm talking about.
OTOH, if I am using an Internet approach, or an intranet, and a router that I had previously traversed in Paris over a TCP/IP connection happens to fail, my traffic merely gets routed around that router to another one, and my inventory updates are delivered on time, just the same.
The next statement may be showing signs of stuck in the mud or legacy thinking here:
>Case in point: how many financial institutions have abandoned their TDM private line networks for IP backbones to date? The answer is NONE! <
Wrong. Financial institutions, including the banks and exchanges and the consortia that support them like the market data feed vendors (Market Data Providers}, and more notably, the Securities Industry Automation Association (SIAC) have gone full bore into TCP/IP delivery platforms for almost every conceivable type of information delivery.
Today's ticker[s] emanating out of the Brooklyn SIAC complex, for example, are delivered to thousands of institutions over TCP/IP.
In many instances, when they do not yet fully utilize IP, it's a matter of preserving or protecting embedded investments. Even some of these are being prematurely written off.
There are, however, a number of critical high capacity applications that will continue to use Layer One and Two technologies for a long time to come. Some of the reasons behind this have to do more with dependencies of peripheral devices on clocking and flow control which are more easily supported by legacy software than they do with anything else that might ordinarily be considered a bone of contention between IP and FR or ATM, say.
But with all respect for what he's said, it will be a long time before local calling and traditional POTS services will be handled over IP.
>IP telephony switch standards are now in place.... Almost entire issues of new IP start-up magazines are devoted to the recently completed IP gateway switch standard, H.323. These magazines claim vendors, (that is advertisers), can now move ahead and start building industrial strength, multi-vendor-compatible IP telephony switches to replace the dinosaur age circuit switches of today. This is a myth. On a scale of 1 to 10, the possibility of H.323 being ready to define the switch of the 21st Century is a 0.1 at most. <
To begin with on this issue, I'd agree that the standards are not currently in place, but I'll go a step further in stating that they, in every likelihood, will never be fully in place, since evolution is not going to stop for a long-enough time, not even an instant, to take a picture that would characterize what's taking place on all fronts.
But he's right, for the most part proprietary solutions are the main focus right now, with time to market being pivotal for those operators seeking to take advantage of the momentary arbitrage window that still exists. And the movement of manufacturers will track those of providers, lest someone else grabs the worm.
I'm not entirely certain where these "myths" are coming from, since I've never seen the official list. Most knowledgeable followers will concede that there is a swarm of harmonization processes brewing right now aimed at resolving many of these issues, and that some of the major switch vendors have already introduced DSL and IP hooks into their switch ports on their flag ship Class 5 monsters, many of which are due out in their next releases.
>H.323 started as an International Telecommunication Union (ITU) standard for video over LANs. The video conferencing folks picked it up because a standard was needed for interoperability of multi-vendor protocols for video conferencing coders, synchronization of audio and video traffic streams, user authentication, authorization (gatekeeper function) and more. In 1996, the IP telephony folks were in search of a standard. Since it takes years to create a standard from scratch, they grasped at straws and blessed the only remotely appropriate standard: H.323. <
True. Perhaps he doesn't take this one far enough. H.323 was an afterthought, along with the entire host of other H.300 family of protocols, to allow the same kinds of isochronous-like [time-sensitive] conferencing arrangements to take place over IEEE and IETF protocols (LANs and Internets, respectively) as was achievable over ISDN lines.
> H.323 has so many shortcomings as an IP telephony switch standard for carrier operation that a 0.1 rating may be too generous. For starters, it has a slow call set-up time because its set-up protocols were designed for ISDN networks. Thus, many packets are exchanged between IP switches before a call is set up resulting in unacceptable post-deadline delays (10 to 20 seconds in some cases), compared to today's circuit-switched networks. <
Again, a matter of cost engineering, resource and facilities sizing, and the other disciplines we've spoken about before. And the tools of the trade can stand a face lift, which is happening as we speak.
>>Second, H.323 uses TMN standards for.. (OSS). Unfortunately, North American carriers in general don't use ITU's TMN for OSS-the glaring exception being TMN for local number portability... Yes, TMN standards will be pushed for LNP and FCC-required RBOC OSS unbundling. But dealing with TMN just to introduce H.323 would create a cost barrier for carriers that wish to use their legacy, non-TMN OSSs. <<
It's interesting to note that the very issues that the author cites here are responsible for a slew of new software vendors reasons for being.
He presents an interesting account of his own views, apparently. He's speaking about network management and OSS platforms and the various architectures and sub architectures that they were created to support. The Telecommunications Management Network [TMN] suite comes from collaboration between the Network Management Forum and the ITU.
The TMN originally made use of CMISE/CMIP and other OSI standards, closely associated in this argument with the PSTN in general. The Internet, OTOH, uses SNMP and various other IETF protocols.
I don't know what the author's point of reference is in citing these conflicts, although it's easy to surmise them being true to some degree. There are many different LNP pilots currently underway, and a government mandated initiative now taking place... which is not going very well, to say the least, I might add.
There has been an arm-wrestling match between the Internet's Simple Network Management Protocol (SNMP) and the OSI CMISE platforms for the past ten or more years. TMN, a newer frame work, originally espoused the virtues of OSI/CMISE almost exclusively, but it has acquiesced in the past year to begin taking into account some integration of SNMP hooks at the lower layers of the model, even if only at the element management layer for now.
BEGIN RANT
Local Number Portability, or LNP, is still in the joke stages, as far as I'm concerned, and if all directories were based on IP at this time, instead of what he have currently, it would probably have gone a lot smoother. {oy! did I say that? well, maybe I'm running a little ahead of myself, but it couldn't be much worse.} Anyone wanting to know why I'm calling this joke-stage, PM me.
But we are dealing with the North American Numbering Plan, or NAMP [unless SAIC and Bellcore have quietly renamed it], and its artifacts and dependencies which run very very deep, and it's going to take a long time to unravel who gets to do what without sacrificing end users' collective patience in the process.
Probably _almost_ enough time, in fact, for the VoIPsters to catch up. LNP doesn't need any help from VoIP, IMO, to get caught up in an engineering quagmire. LNP has done just fine in this regard, on its own.
END RANT
But more to the point, there is no binding set of rules that states that a service provider must be compliant to TMN, SNMP or OSI CMISE, etc. Carriers use all of these internally, although in many cases the legacists win out with the CMISE approach, and probably justifiably so, because of its more robust framework and added administrative handling capabilities.
When carriers grow to regional and then national, international size, they must administer to the parameters of that venue among hundreds , thousands of other providers, and SNMP just doesn't cut it.
You can expect the Internet community to begin looking at CMIP/CMISE more closely from this point going forward. I say this because of the arena they are entering, and when in Rome, etc., but more importantly, because of the increased burdens and complexities that they will face re: network management, as they take on newer and more complicated service-related responsibilities.
It's worth noting here, however, that these were never the concerns of the original Internet architects and their eventual following, for they probably never took the possibilities of today into account, until just recently [relatively speaking] when they previously molded these network management tools.
The next realization he reaches, I reached about 18 months ago, prior to the VOIP Forum draft, and folks [including some of the players out there today boasting International VoIP services] thought that I was nuts to try to integrate these two sets of principles:
>>... it is lacking the fundamental requirements for interfacing with SS7 for AIN features including LNP.<<
But these have now come into industry focus for all to comment on, and the various factions and standards bodies are now taking them into account in the protocol reconciliation processes.
>IP over xDSL is ready for mass deployment...The reality is that the variety (x) of digital subscriber line (DSL) approaches permitting MBPS end-user access over existing copper loops technologically may be ready for rollout, but the RBOCs may get cold feet about moving ahead. First, to make xDSL access work from a service and business case perspective, an RBOC will need a national IP backbone network to cache selected Web sites, such as @Home and Roadrunner created for the cable industry and cable modem access.<
Wow. He's saying that in order for an RBOC to provide DSL services, they must also be the service provider who will supply web services too! I wonder at this, whether it was intentional or not.
>It doesn't make sense for the RBOCs to massively deploy xDSL for high-speed access to ISPs, only to shift the bottleneck from the loop to the ISP! <
We've spoken about this before, the shifting bottleneck phenomenon, resulting in an implosion of sorts of the 'Net. Sucking sounds reversing in their directions.
The " ISP's " edge could really take a hit, granted.. IF they don't size up appropriately through leasing more facilities from their peers and the carriers who get them from here to there... but since when has this ever bothered the ILEC when dedicated access lines were involved... which is what DSLs would be in this case?
It's when the ILEC's "own" edge resources take a lickin' that they get upset. If they are leasing the facilities to someone else, they couldn't care less, and it may even serve their purposes better if that were to occur to smaller players. The former condition, however, where the ISP incurs the increase of traffic, would only result in the ISP ordering increased capacity from the ILEC if they wanted to preserve a proper capacity balance, or am I missing something here?
>The RBOCs will have to solve the problem of local IP Web caching.<
Again, this would only apply if the ILEC themself (or RBOC as they are referred to in the article, ignoring the other 1100 or so independent ILECs) were the actual Internet Service Provider, as well. I don't think that this concept of jurisdictional separation is clear to the author.
>So far, the regulators have not allowed the RBOCs to deploy national or interLATA networks for such Extranet services until they unbundle their OSSs for the CLECs....Second, if the RBOCs push ahead with xDSL deployment for Internet access, they will have to do it with unregulated subsidiaries, which lease unbundled loops from their regulated parent companies. If this occurs, they will break the bottleneck they created (i.e., restricting the CLECs from leasing unbundled loops)....Finally, if the RBOCs start offering unbundled loops for Internet access via (high bit) HDSLs, they will cannibalize their T-1 access business. HDSL, with two unbundled loops at about $15 per month per loop, doesn't replace the revenue from a T-1 at $350 to $1000 per month<
Some very good points, although I don't agree entirely with the price points he's suggested, but they are the author's and not necessarily those of the carriers, so it's difficult to discern who it is exactly I should agree with or disagree with here... and let's not forget this list of myths and wherever on earth it came from.
There are about 300,000 residents in my immediate two mile radius here in Brooklyn, NY, many of whom live in the Bay Ridge and Dyker Heights Sections, and I know of only one of them who has a T-1 to host a web site! Many are using ISDN, more of them however are using 33.x and 56 k.
If xDSL were to be unleashed here, its uptake rate would be overwhelmingly phenomenal! The problem is that I have serious reservations about the existing plant built out to support additional strain at this point, since the supply of copper is already under heavy tax due to second and third line orders. In my home alone, there are four lines, currently, and I'm ordering a special purpose ISDN line for remote access services. Between installations and repairs, I've gotten to know many of the local BEL craft and first line management this way.[g]
The cannibalization issue gets long in the tooth in some respects, is what I was starting to say before I interrupted myself. It was a convenient thing to cite in its novelty stage, especially where commercial districts are the issue, but when viewed for its enabling and application releasing qualities, I don't think it applies any longer, and even the ILECs will have to come to terms with this reality sooner or later. Otherwise, they will wind up taking it in the nose to spite their own face.
This does not discount, however, other motivations that the ILECs may have for holding back.But those are only speculative on my part. Just a word on this, though, I don't think that they have yet found a way to economically deploy a full service area network (FSAN) environment yet, true to the ultimate model of the DSL camp, with the wares that are out there right now in a mass deployment fashion.
And the FSAN would enable them to meter more readily every bit that goes in and out of "their" networks. This way, when interlopers come along and want to resell those facilities, they can charge them by the
megabit, and make their own [ILEC] bundled offerings appear to be more competitive. Can you spell ION?
Getting back on topic, though, worse for the ILEC to consider, and I'll bring this back to my own back yard, is that TW is said to be readying their last mile capabilities to include voice and Internet access over their coax feeds [not so much here in Bay Ridge as in Manhattan at this time], just as RCN has already done. This threat, on top of the potential added revenues for doing an ADSL rollout, only spells incentive, in my book. And let's not forget the other threats being posed at this time by a growing number of VARs such as Covad and others, who are finding ways of breaking down the negotiation barriers within ILECs' territories.
>IP will generate 50 percent of wireless revenues by the year 2003.<
Perhaps IP will walk into 50% of the "volume" of _today's_ wireless traffic, but by definition, that would render a lower percentage of overall 'revenues' for the very reason which are cited to explain why IP is less expensive to operate. Although, in wireless technologies such as cellular and pcs, compression schemes are already pressing the operating-quality limits, much the same way they are in VoIP.
This is the same old trap that ITSP venturists fall into, and that is by saying that if they capture 10 % of a $1 Billion market, then they will necessarily gross $100 Million. The error in this way of thinking is that if they are only charging 40 % of the going rate, then their share of overall revenue will only be 4%, not 10%, resulting in a $40,000,000 and not a $100,000,000 share.
But there is an offset to this: New reasons for using the technology, mainly affordability, at first, resulting in an increase in overall traffic sent. But can the upstarts scale to these new traffic levels made possible through technology's enabling characteristics if their revenues don't take into account total cash flows that will be crucial to support growth?
The author presented a lot of good ideas and areas of contention, and in many ways his observations, IMO, were correct, and in some ways I thought he was missing the mark where I have so noted. This is a very fluid area we're dealing with right now, and much of what he's stated in the article, and much of what I've stated above, could get tossed aside with tomorrow's press releases.
It's good to stay on top of these things during fast moving times to maintain a sense of what's going on, but it probably makes a lot of sense to wear a seat belt, just the same.
Best Regards, Frank Coluccio |
