Anyone who has ever planned a project knows that there is more difference between voice and data than simple information representation. Voice projects are usually based on dial-up networking—telemarketing programs, for example. There is no protracted planning and justification process involved; you pick up the phone. Data projects are traditionally based on semi-permanent connections and capital hardware, and the planning and justification phase is often years in length.

OK, so what? The problem is that businesses need tactical data support to the same extent that they need tactical voice support, and they aren't getting it today.

Imagine the dollars spent on private networking today as a stack of coins ten coins tall (yes, they are large-denomination coins). Reasonable growth in the current application paradigms for the future could create an additional five to seven coins in that stack. That would incorporate everything we call "intranets", for example. The Internet today is about two coins, and it could reach as much as 20 coins in the future.

What would add the most coins (40, to be exact) is support for tactical data-oriented projects. Our research shows that businesses are already eager to consume tactical services in the data space, and in fact are already presenting projects to carriers. It's clear that at least some planners are hitting tactical data opportunities, and it's worth considering what these opportunities are, and how they might be addressed.

Our current networking strategies are based on business paradigms as much as on technology. In the 1970s, the US had relatively low private line rates, and this encouraged the companies building large data networks for reservation and financial systems to depend on private networking. Hardware purchased by the end user was combined with private line technology to create a "network".

For the purposes of our discussion here, it is the project style this created that is important. We had a big business need—a major data system driven by networking. We had a project to satisfy it.

The problem with this model of data networking is that many opportunities to consume data services don't start as big business needs creating big data systems. The project model of networking means the whole networking game is driven by clocks, not technology.

The first clock is the clock of capital equipment depreciation. We all know that technology components have to be written down over a period set by the IRS codes—generally, three years. When hardware is installed, the depreciation clock starts, and an expense is generated each year (a third of the cost, if straight-line three-year depreciation is assumed). This expense must be offset by benefits, or the impact of the purchase is a reduction of net profit.

If the benefit case ceases before the depreciation clock has wound down, the result is a premature write-off of the excess (unused) depreciation. If something displaced the hardware during the depreciation cycle, the excess depreciation must also be written off. In this case, the displacement depreciation becomes an expense to the project that did the displacing, making it harder to get that project justified.

That gets us to the second clock, the expectation of useful life clock. That's the period for which the equipment being purchased could be expected to have utility. If the expectation of useful life is beyond the depreciation cycle, there is every reason to expect the equipment to remain useful to the point where it is fully depreciated and beyond. If not, a write-down may be required.

To complicate matters further, companies typically have a minimum internal rate of return (IRR) their projects are expected to meet. This is sometimes expressed as a return on investment (ROI) figure, in percent form. The IRR requirement may set a payback period limit which is less than the depreciation cycle.

Sound complicated? In fact, it's the complexity we're trying to get across and not the details. The fact is that when all this project justification stuff gets invoked, it tends to force business to project fairly durable benefits in order to justify what is going to become a sustained expense. If a project has only short-lived benefits, those benefits will generally have to be fairly incredible in order to carry the expense and write-down of equipment that would result when the benefits aged away and all that was left was the cost.

Tactical data networking seeks to eliminate this project process, and thus to allow data resources to be employed to serve business goals too transient to justify projects or too weak in benefits to justify special expenses at all. There is about $8 billion per year in data network opportunity created in this space as of 1998, and the number is growing. By 2010, the US opportunity for tactical data services will exceed $40 billion. Worldwide opportunity could nearly double that.

Realizing that opportunity isn't necessarily easy, however. We can identify the key elements fairly quickly, but the devil is in the details. The major requirements for supporting tactical data applications are:

1. A public data network architecture that is fairly ubiquitous. Here, public IP services are the obvious example.
2. Convergence on this architecture at the application level, to minimize the amount of interface or protocol matching that has to occur to mate the application to the public network. Fortunately, we are converging on TCP/IP, so this requirement is also being met.
3. Access connections to the public IP network whose residual capacity is significant, so new applications can be added without refitting either the access line or the CPE that terminates it. Here, we have a problem in most corporate sites today.
4. Selectable service quality levels at the interface, so the business service quality needs of applications can be met. Today, public IP (the Internet) has no such capability.
5. Flexible billing plans so that tactical projects can be billed on a usage basis while more enduring projects are billed on a fixed price basis. This is also not available today with public IP data services.

Most organizations who have explored tactical data networking will quickly recognize the value of these points, and quickly realize that they've been trying to get the Internet (the only public data network that is truly ubiquitous) to serve as the tactical application foundation.

The problems with the Internet in this space are formidable. First, buyers rate Internet service as the worst network service they procure today. In our fall survey cycle, businesses again rated Internet services as "unsatisfactory 20% of the time or more", the worst category we define, in an astonishing 82% of cases. But there are other problems as well.

The service quality and billing problems associated with tactical applications are probably the most difficult to fix in the near term. In general, the Internet has been based on fixed-price service because in content-valued networks, buyers will often overestimate their likely level of use. Buyers also fear dependence on a pay-as-you-go resource because it exposes them to a large upside cost.

The fixed-price nature of the Internet has acted to deter ISPs from solving the QoS problem. It's hard to define premium service levels in any connectionless network, and harder still when the network is made up of a number of carriers, all of whom may not offer QoS, and whose QoS strategies may differ even where they exist. Yet all business applications of communications have an intrinsic QoS requirement, and tactical applications often have more stringent ones because they react to immediate conditions.

We aren't going to solve the problems of the Internet; we're going to slowly morph the Internet into "public IP", which will run today's Internet and corporate VPNs as applications. During that morphing process, we'll see spotty support for tactical data applications, and buyers of data services may want to watch for this support, and plan to exploit it.

The first step in preparing for tactical data applications is to insure you have a public IP option that can support QoS-specific virtual private networks. Assuring that is less an issue of technical review than of contract development; if the carrier is willing to provide service-level agreements that define throughput, delay, and loss rate, they are worthy of consideration.

The second issue to be considered is the access connection to the carrier. To be an effective vehicle for tactical application-building, a service must have about 30% residual capacity during normal busy-hour periods. That means utilization levels during the busy hour of no more than 40% in most cases. Most companies will find that only fractional T1 or higher can offer this.

The third issue relates to the way that new service can be consumed. Ideally, tactical networking should be supported by a service that can be turned on in an instant. This implies some form of service QoS reservation approach, and a very reactive billing system.

For the tactical buyer today, it's hard to get all of these capabilities. QoS is available in frame relay SLAs, but most ISPs who offer SLAs will guarantee only availability, which they tend to define as meaning that there is a live router at the end of your access line. Usage pricing is a factor in some ATM SVC offerings, but is generally not available in IP services.

Chances are, tactical opportunities in the data space will have to be satisfied through the channel of the ISP in the near term. Many companies have a corporate connection to the Internet at headquarters, but some don't have similar capability at the branch level. If that capability is added, the Internet could be used to satisfy tactical requirements.

The big barrier there is QoS. The Internet isn't QoS-capable, as we've noted. Fortunately, there are steps being taken to make at least some QoS control on the Internet workable. Thus, for the near term, the tactical data application planner should consider the Internet a stepping-stone.

The last issue to be considered is the question of planning paradigm. Most companies today don't really consider data networking as a project option while in tactical mode, because they're too conditioned to the limitations of private networking and the associated project time-lines.

One way to alleviate this in the near term is to try to cast tactical projects in an application light, rather than just thinking of "networking". Many organizations already use e-mail as a means of communicating around the company. E-mail, augmented with MIME or UUCODE file attachments, can be used for workflow automation, distribution of order information, and a host of other applications. The fact that e-mail is not real-time in nature may be a barrier to some applications, but even knowing such a limitation exists may help to develop an alternative application slant.

Such a slant is likely to be something like NetMeeting or another form of real-time collaboration. This style of application can be used for videoconferencing (with some restrictions), for long-distance team-building, and even for business applications like commercial loan support.

With both e-mail and NetMeeting applications, companies can consider what to do with networks rather than how the networks happen to do it. If these applications are used in conjunction with an ISP who provides some reasonable intra-company QoS among the sites "on" that ISP, it takes a step forward in tactical data networking.

In the long run, we'll have to do better than just the Internet. In the future, we'll be talking about the ways that public IP can be enhanced by developing the evolution of public IP infrastructure from the structure of the Internet, and the structure of current carrier virtual networks like frame relay. The improvements we can expect will make service quality and billing more flexible, and that will enhance our ability to rely on these tactical services for business problem-solving.

The topic of IP version 6 (also known as IPv6 or IPng for "new generation") is one that often provokes strong emotion. Corporations are today involved in an accelerating transition to IP-based networking, and invoking the name of a new version of IP that threatens to require complete overhaul of the IP infrastructure doesn't seem a good way of encouraging this transitioning trend.

Good or not, IPv6 is a topic we have to examine. It is possible that the current version of IP (version 4) will be adequate for years, but "years" probably won't mean even "a decade", and it may mean a lot less.

We must open this discussion with the statement that we're not big fans of IPv6; it could have been done better. We are, however, resigned to the fact that IPv6 migration is inevitable, and the sooner we face the issues the better off we'll all be.

The primary motivation behind IPv6 is the problem of Internet addressing. Version 4 of IP has a 32-bit address field. This field is subdivided to create a total of 126 Class A addresses, 16,384 Class B's, and 2,097,152 Class C's. This creates a total address space of about 3.7 billion, which on the surface would certainly appear adequate.

It isn't, though. The Class A addresses are for practical purposes all gone—eaten by universities and Government agencies. Most of the Class B addresses are gone, too. In the US alone, there are about 5.76 million businesses who might want Internet access. The total number of Class A, B, and C addresses is only about 2.1 million. Most addresses remaining are Class C, which offer only 254 stations/servers per address. That's too small for many companies.

What has gotten us through to this point is the fact that most corporations today aren't IP-dependent. Thus, most don't have an IP address of their own. As that fact changes (as it surely will, given the success of the Internet as a corporate advertising mechanism), the current address space gets eaten up.

Then there's the problem of direct attachment of residential users. Every cable modem or xDSL connection eats an IP address. At some point in time, the ISP providing the connections runs out of his own allocation space. Today, dial-in contention prevents any more than about 15% of the user population from being on the Internet at any given time, and thus limits the number of addresses that get consumed. Always-on direct attachment means always-on addressing.

IPv6 was motivated in large part by the need to develop an IP addressing plan that we couldn't run out of. With a 128-bit address, IPv6 could provide so many addresses that it's hard to conceive of any way we could exhaust them. Certainly it provides enough addresses to accommodate all of the projected uses of IP through the lifetimes of our readers (and ourselves).

Making a change to IP has an impact, of course, and while the change in address space was being made, a lot of other changes got tacked on (much the way that amendments get tacked on to Congressional bills). IPv6 also provides new or improved features in each of the following areas:

• Enhanced QoS control, through a richer type of service (ToS) field and through the use of flow labels to uniquely identify any information flow that will require special handling.
• Improved security, for user authentication, content integrity, and content confidentiality.
• Extensible header structure to permit easy addition of new features in the future.
• Hierarchical addressing structure to facilitate address assignment in a multi-jurisdictional administrative framework. This is similar to the X.121 addressing of packet networks, which provided data network ID hierarchy as opposed to the North American Numbering Plan, which provides geographically hierarchical phone numbers.
• Support for interoperation with IPv4, both in features and addressing.

Addressing features associated with IPv6 would require changes to devices that assign or provide addresses (directory servers like DHCP and DNS) and with host software (the TCP/IP stacks). The other features might require changes at a higher layer, eventually making their way up to the API level. That would mean special application support for IPv6, something that could take a long time to provide.

That "long time" and the implied software and hardware upheaval is the big issue with IPv6. Nobody doubts its benefits, but some doubt whether they are justified given the cost in terms of network change.

IPv6 headers look a little like standard IP headers. There is a version number (4 bits), a priority-type-of-service field (4 bits), a length field, a hop count (time-to-live), and addresses. IPv6 adds a flow label and a next-header link that serves a role similar to the protocol type field in IPv4.

The address structure is clearly what makes IPv6 different. Each address field is 128 bits long. The top three bits classify the address types, somewhat as is done in IPv4. Each 3-bit class has 1/8^th the address space to work with.

Reference to the addresses is made in hex format (unlike IPv4, which uses decimal), with the bits grouped in 8 groups of 16 bits each, separated by colons: "x:x:x:x:x:x:x:x" is the preference. A group of zero can be omitted, making two colons as "::" to represent the zero value. This is because so many IPv6 address bits are likely to be zero that the nomenclature would be awkward otherwise.

IPv4 addresses are mapped into the IPv6 space by defining six groups of zeros (0:0:0:0:0:0) followed by the IPv4 address (which can be noted in the old decimal fashion). A similar address (0:0:0:0:0:0:FFFF:d.d.d.d) is provided as a unicast address for those IPv6 devices that provide a facility to tunnel IPv6 addresses over an IPv4 network. The "real" IPv6 address space can be based on geography, provider, or local-use subdivision of the address space. There is also a special provision for mapping NSAP and IPX addresses to IPv6 space.

Local use addresses mimic the capabilities of RFC 1918, with extensions. One interesting capability is the containment of the MAC-layer address within the local-use address. This makes the IPv6 address self-deriving for a node, potentially eliminating the whole ARP process.

The provider form of addressing would be based on a hierarchy of addressing:

1. Registry ID , the identification of the registration authority that assigns addresses to providers.
2. Provider ID , the identification of the particular ISP assigning the address and providing the service.
3. Subscriber ID , identifying the particular subscriber.
4. Intrasubscriber/Interface ID , which identifies the system within a subscriber.

The size of each of the fields above have yet to be determined.

IPv6 has expanded multicast/broadcast capability. The group ID field is larger in IPv6 (obviously), and the multicast address has a scope field to indicate whether the multicast group is local to a node, link, site, or organization. IPv6 also adds an "anycast" concept, which supports selection of paths and providers in complex networks.

Routing in IPv6 works pretty much as it does in IPv4; the common routing protocols are extended to the IPv6 address space. One interesting IPv6 routing extension is the ability to provide source-route lists—vectors that specify a path. This capability can be used to facilitate provider selection, path selection where alternatives exist, and rerouting to accommodate re-addressing or mobility applications.

The other features in IPv6, like QoS, are features that would have to be accommodated in the network nodes, the applications, or both. Thus, simply implementing IPv6 won't necessarily get you those features. This is why it's not realistic to view IPv6 as the solution to connectionless QoS. To the extent that IPv6 can solve that problem, IPv4 could solve it too.

More information on IPv6 is available on the Internet. Some of it (RFC 1884 that defines the address handling we've summarized, for example) is pretty solid. Other aspects are still in the draft stage, and it may be helpful to look at vendor home pages (Cisco, for example) and follow their links to other material.

The most immediate problem with have today on the Internet is the shortage of corporate IP addresses. There simply aren't enough sanctioned addresses to go around if most businesses elect to publish information on the Web.

Part of this problem can be alleviated by having companies use the so-called "private" IP address space offered by RFC 1918. This would allow every corporation to have a Class A or B address for internal use. They'd have to perform an address translation to a sanctioned address for every employee-to-Internet or Internet-to-resource relationship active at any point in time, because these addresses are not unique.

The question is what address they'd translate to. It's hard to imagine any corporation of any size that could accept a single Class C space as their sanctioned address space (no more than a total of 254 workers or Internet servers could be active on the Internet at a time). Since there are only a bit over 2 million Class C addresses, we can't equip all corporations with the addresses they'd need.

Given this as the primary problem, there are two ways we could move forward:

1. Convert to IPv6 in general.
2. Convert to IPv6 on the Internet only.

Converting to IPv6 across the full population of users and content providers seems a bit unlikely. Certainly it would take many years, and during that time it would be necessary for most IP hosts, users, and routers to accommodate both address types.

Converting on the Internet only seems a less intrusive concept. The theory is that the real problem with IP addressing in the near term lies in the public space, so why not confine our solution to that space, minimizing the impact on the rest of the world?

On the surface, the idea of upgrading the Internet without upgrading corporate networks seems reasonable. Corporate users would adopt the RFC 1918 Class A address (10.0.0.0) internally, and use network address translation at the firewall to map into a sanctioned IPv6 address space assigned to each company. Nobody's local stack would have to change, but the Internet routers and DNS would all have to change to support IPv6 addressing.

Unfortunately, it's a bit more complex than that. If we assign addresses this way, the IPv6 address associated with a given user would be known only at the point where the mapping took place, which would prevent any user with a remapped address from being known by a logical name (a DNS name). That, of course, is also true if we remap RFC 1918 addresses to real IPv4 addresses, and it's solved by giving Internet resources (content providers) fixed addresses.

In what address space? If we give them IPv6 addresses (meaning real ones, and not just IPv4 addresses translated into the IPv6 space), we'd need a real IPv6 protocol stack to talk to the resources, which would require all the client systems be upgraded. That defeats the whole "limit-the-impact" objective.

OK, we'd map our content providers into IPv4 space. But doesn't that take us back to where we started with respect to addressing limits? In a way, but not completely. In fact, this is on the trail to the only way that IPv6 will probably be able to deploy. What happens is that we establish a rule saying that corporations have both content resources and inquiry resources.

The content resources must be given IPv4 addresses so that they can be addressed by anyone, no matter what their protocol. They must also have IPv6 stack capability, because they'll have to interoperate with clients in both address spaces. Remember, this applies only to resources that publish on the Internet.

The inquiry resources are assigned RFC 1918 addresses internal to the company, mapped to temporary or permanent IPv6 addresses at the exit firewall to the Internet. These addresses are compatible with the content resources because the latter have the IPv6 stack.

Now, we've removed from the addressing problem all those inquiry resources who never need to have a DNS entry. We consolidate the IPv4 address space to recover these addresses, and turn them back to be used to address other content resources as they come on line. That buys more time for conversion to IPv6.

If any organization wants to stay IPv4 internally, they follow this procedure. If they want to be IPv6 internally, they can use their sanctioned addresses in the IPv6 space intra-company and on the Internet, which are compatible with the stack architecture of the content providers.

At some point in time, it would become desirable to stop using the dualistic structure. At any point, a company would be free to publish information based on an IPv6 address only, which would make then inaccessible to IPv4-addressed clients (because their address couldn't be mapped uniquely into the smaller IPv4 space). If this started to happen, organizations would begin to shift to IPv6 to get access to the full Internet content, and the migration would be self-paced.

In order for this approach to work, we'd have to be able to get IPv6 routers, DNS, DHCP, and protocol stacks for the host environments that publish content. Can that be done? In fact, it can. There is even a 32-bit IPv6-compatible stack available for Windows 95 and NT. Cisco and others make router and Internet server products that are compatible. In short, it could happen.

Software used in client-only applications, and small router-like products used to support "always-on" applications would be relatively easy to change; only a software upgrade is required on a PC and the always-on interface boxes aren't deploying in large numbers yet, so it would be possible to make these devices IPv6-ready. Again, it could happen.

In fact, it might be worthwhile for some companies who are looking at using RFC 1918 to consider IPv6 instead. An internal IPv6 address space large enough to support a company's needs via sanctioned addresses rather than RFC 1918 would be obtainable. This would have to be mapped to a sanctioned IPv4 space at the Internet boundary, but so would a 1918 address. The IPv6-equipped company would be well positioned for the inevitable migration.

The current IPv4 strategy is probably good for another three years without any changes. Beyond that, something would have to be done. The "get-the-Internet-to-IPv6" approach outlined here would buy another three to five years, at the minimum. By 2007 or so, we'd expect IPv6 to be pretty much inevitable.

Is this too soon to worry, then? If one assumes that the Year 2000 problem is real (make your own assumptions there, folks), then it is clear that the process of thinking about it was started too late. In fact, whatever problem there is could have been dealt with painlessly if the issue had been raised in the late 1980s. The same is true with the IP migration. Think now, or pay later.

We talked last month about the issues related to making high-speed, permanent, Internet connections for residential or casual users. That issue was dedicated to the airing of the overall situation.

This month, we'll examine one specific solution path—cable modems. We'll look at the basic technical approach, the business model, and the role that cable modems will likely play in the future.

We have to start with a summary of the politics. Two technologies have been presented as solutions to the high-speed, always-on Internet problem; cable modems and xDSL. The former is a strategy that exploits the current CATV hybrid fiber/coax plant. The latter is digital augmentation of the current copper loop technology used in local telephony.

From the start, cable has seemed an outside shot at best. Cable plant is notoriously unreliable, with the average user still indicating they have one outage every one to two weeks. Cable companies have also been spotty in their adoption of cable modems, and some have almost seemed uninterested except to use the future promise of cable modems as a weapon against DBS video.

On the other hand, the public carrier people seemed to be on a roll with xDSL. First, it offered transport asymmetry that seemed appropriate to the unbalanced traffic associated with residential Internet use. It also promised high bandwidth—in the one to six megabit range.

Regulatory issues have derailed xDSL for now, and opened the way for cable modems. Even though they are generally limited to 500 kbps to 1 Mbps rates, they still offer better transport performance than even ISDN, and the cable companies aren't limited by the Telecom Act and its legal ballet. Cable may have a chance, if it moves quickly.

The cable television outside plant is already being used to transport high-bandwidth traffic, but in analog form. The RF signals that drive your set or set-top box wouldn't be impacted by the cable's use as a data delivery mechanism. Instead, a digital channel would be modulated onto the cable to create a bi-directional conduit to a data network head-end interface point.

The cable (or a part of it, probably at a neighborhood level) creates in effect a shared-media LAN that is made up of a shared upstream and downstream digital channel modulated onto the cable. These channels are what the cable modem interfaces with.

At one end of the cable is a CPE device we call a cable modem. It provides interface with the local PC or PC LAN via an Ethernet interface, and it probably provides basic router or at least filtering functions.

At the other end of the cable is a compatible modem that provides a link into the data network, presumably the Internet. This linkage could be provided in a number of forms, from ATM to Ethernet. Effectively, this device is the default gateway for a logical independent subnet (LIS) whose members are the households on the cable span.

The exact cable modem technology picture is fuzzy at this point because there are two competing standards, representing two viewpoints on the technology's direction.

The Multimedia Cable Network Systems (MCNS) standard is promulgated by key players in the cable market, like Comcast, Cox, TCI, Time Warner, and Rogers. The consortium collectively represents about 82% of the market in North America.

MCNS' priority is market timing. They recognize that regulatory overhang is holding back xDSL, and that problem will probably go away within 2 years. In the meantime, they see a green field for the cable modem players, and they want to boogie on it.

MCNS plans to utilize a packet-mode interface across the cable, providing what looks very much like IEEE-based LAN service on a shared media. This approach tends to limit the applications of cable modems to the data space, but it represents something that can be quickly and cheaply deployed, and it doesn't tax the current cable plant.

The MCNS standard doesn't foreclose the use of ATM in the network, just on the cable. The back-end (network-side) interface can be ATM, and this would allow IP-over-ATM architectures to be used to deploy service. The current specification calls for an RFC 1577 relationship between the ATM/IP core network and the cable spans, but that may change as new technology options like MPLS are presented.

The IEEE 802.14 standard takes a very different approach. With this standard, the goal is an enduring architecture suitable for the full range of services a cable provider might want to offer, particularly voice or isochronous video.

The foundation technology for 802.14 is ATM, which connects across the cable and provides a flexible set of QoS options that could incorporate all service types into a cable modem network. The problem with the approach is that its cost in the near term is likely to be high, and the standard has yet to be completed. The combination is viewed by the industry as negative because it almost assures xDSL will have a shot at the buyer contemporaneous with 802.14.

There are still some issues in this space that need to be resolved. The MCNS standard seems to leave open the risk that individuals on the shared cable media could "hog" the capacity if they were highly active. This is the same problem presented in dial-up modem networking, but some feel the potential for abuse is higher here because always-on cable modem connections could be used for information publishing by small businesses, and for telecommuters. Both these application classes would present sharply higher traffic levels than standard residential use would offer.

Another issue that may be a factor is security. While the cable modem per se can guarantee that on-media traffic to others doesn't get presented into a given residence, and that local LAN traffic isn't exiting onto a shared cable, it's possible that someone could replace a "standard" product with one that could intercept media messages destined for others.

In fairness, neither of these issues is resolved to perfection in the ATM space, either. There is also a real chance that waiting to resolve them may mean defeating the whole cable modem paradigm. In fact, they can be solved within the MCNS architecture through the use of encryption.

We think that any form of always-on technology for Internet access is probably going to become somewhat dependent on encryption for privacy. Business applications like telecommuting will certainly require a form of encryption because the risk of company data or security passwords being compromised on a shared-media connection is simply too high. People may also be reluctant to use shared-media systems if they believe that their traffic could be watched by others.

Tunnel-based security options could be applied to cable modem networks relatively easily, and at a modest cost. To be sure, there is no easy way of preventing low-cost systems from being broken, but it would be enough to halt casual interception.

A more durable strategy is also available; the same kind used to secure pay-for-view channels. If the cable modem has a secure and intelligent control link to the cable network control center, substituting another product to breach security would be detectable. Again, this won't work at the level needed to prevent intelligence agencies from intercepting traffic (if you believe Big Brother is really watching), but it would be suitable for most applications.

Overall, we'd have to give the nod to the MCNS approach. There is no indication that cable companies really want to get into the phone business—they just want to scare the RBOCs into thinking they do. Even if they did, there is no sure way to know what the requirements of such a multi-service relationship would be, and whether products designed for a flexible 802.14 standard would end up being as flexible as the standard allowed, given cost control objectives inevitably associated with early deployment.

There are already hundreds of thousands of cable-modem-equipped households using MCNS-type equipment and getting access to the Internet. So far, cable companies have been stressing the service in the form of a bundle accompanying premium channels. Typically, the cable company offers a bundle for about $120 per month, and the bundle includes basic cable and premium channels worth about $40 to $60 per month. The cost of the cable Internet service alone (if offered) is about $90, so the homeowner is faced with a "basic-cable-plus-Internet" cost of $110 to compare with a bundle cost of $120.

User experience with the cable-based service is generally positive so far. Transfer rates are obviously much faster than for dial-up service, and reliability seems good when compared to the uncertainties of dial-port access today.

The fly in the ointment is that the typical systems today are so under-utilized that a given cable modem user doesn't collide with much of anyone. In many respects, it's like the good old days of the Internet when hardly anyone really knew what to do with it but paid willingly to get an e-mail address on their business card. As usage increases, the cable companies will be faced with the same problems as the ISPs had when user literacy went up—build out at a lower rate of return, or let usage climb and performance fall.

Cable companies aren't known for their social consciousness (that's why we're complaining that they've taken advantage of the deregulation of rates under Telecom '96 to price gouge). It seems likely that performance on cable modem data networks will get worse as usage (customers and per-customer activity) rises. Whether that will leave users with enough value to justify the higher cost remains to be seen.

There's also the issue of regulation and xDSL's now-inhibited growth. If Telecom reform were to be suddenly un-mired from the legal process, it could quickly release the barriers on xDSL. There is even some indication that certain facility-based carriers would take their regulatory chances and deploy xDSL even today. Both US West and Ameritech are doing just that.

The future of cable modems is still unclear, and it probably can't expect more than a head start on the xDSL players at best. Once both technologies are offered, buyers will congregate to where value is highest, and cable providers still seem a little less than ideal partners to nearly all businesses and even to many residences.

In the next issue, we'll take a look at the technical/business structure of the Internet itself, and examine how that structure relates to both the growth of high-speed subscriber service and the growth of VPNs. We'll also continue our technology examination with a review of the xDSL play.

Access the index of CIMI Corporation's recent newsletters.