Netwatcher (ISSN 0890-5800) is a monthly publication of CIMI Corporation. Subscription information is available here. Copyright © 2000, CIMI Corporation. All rights reserved. No publication or reproduction of this document is permitted without the express written consent of CIMI Corporation.

Management Briefing

This section is being omitted this month to provide space for the Lucent VPN response offered to our subscribers.  Sorry!

In the Know

Over the next four years, we’ll see the incumbent LECs deploying ATM-based access networks on a truly grand scale.  These networks will revolutionize the way we use communications services.  In many respects, they’ll usher in a period of change as radical (or more radical) than the shift represented by the Internet.

Today, the average household has a simple dial-up data capability, offering a few tens of kilobits per second of bandwidth, and requiring that users make a connection to the Internet when they desire to originate a request or receive a response.  In five years, the top-end residential users and business sites not empowered with other technology will all be linked to public data services (including the Internet) using always-on digital services running at a megabit per second or more.

The public policy goal of the Telecom Act (if one will accept the idea that the political process could serve a public policy goal) was to eliminate the access infrastructure constraints on public networking.  That goal can be accomplished through the new broadband networks, but we still have to ask the question “What services will be associated with the new public network?”  After all, the purpose of access changes was to empower users, which happens only if those users are then offered something they want over the access connection.  In short, were the access “constraints” of the past constraining anything?  If so, what?

Of course, it wouldn’t be surprising if the vision of what we’d do with an unconstrained public network and the actual spectrum of useful and commercially viable services were different.  In our review of the broadband services of the future, we’ll try to deal with both perception and reality.

A related topic for consideration is the impact of the new services on the IP protocol set.  Since the only advanced information appliances likely to be popularly available “speak” the IP protocols, we must either fit new services into the context of these protocols (a neat trick in some cases) or adapt them.  We’ll deal with this issue as well.

What Song to Sing?

So far, our view of the future services of a multi-service public network have been rather simplistic.  People talk about “streaming audio”, which would presumably replace broadcast radio, and “streaming video” which would target the TV/cable/movie rental spaces.  All of the experiences these services target are either free or very cheap, which begs the question of what the commercial incentive to provide them would be.

It seems likely that the early opportunity for new services would develop from one of the following three areas:

1.       Evolution of the current Internet experiences, particularly in the form of expediting the behavior of some applications that are now running on the Internet, such as software downloads.

2.       Evolution of the current applications for private networks (including frame relay) to public IP services.

3.       Creation of new applications that could not have worked effectively in the old network, but are now enabled and valued.

It doesn’t take rocket science to realize that these opportunity areas don’t exactly generate an immediate social revolution or an explosion in activity.  There’s a number of reasons for that, each worth exploring.

Reason one is price expectations in the current market.  The Internet is not incrementally priced today, and the mass media seems fixated on the idea that somehow networking is going to be free in the future.  That puts a certain amount of negative pressure on service ideas that are based on pricing some parts of the Internet experience at a premium to basic services.  In fact, the low monthly cost of the Internet tends to put downward pressure on any future services.

Reason two is the inertia of current business practices.  Private networking works.  New public networks might also work, but then they might not.  Businesses who are not excessively cost-adverse may decide to stay the course rather than change their existing applications over to new service types.  That has been the case so far, with frame relay penetrating less than a quarter of the way into leased-line service installed base.  Furthermore, the same inertia may make it hard to create new applications.  Business practices and policies tend to change as a result of opportunity or regulatory pressures, not technology pressures.

The final reason is that the business model of the service provider industry may take years to stabilize.  We are moving from a model where some providers (in dollar-market terms, most providers) were limited in the range of services they could offer.  Those limits are being removed, but the changes in the regulations are triggered by competitive behaviors (the famous 14 competitive points of the Telecom Act), and won’t all occur even in 2000.  Even when the entire market is effectively deregulated, there will still be some transfer subsidization, wholesale requirements, and other business factors that will make it less a truly open market than a partially regulated one.  The hysteria of the media and financial communities also contribute to the lack of quick retrenching; there is no easy forum in which to develop an effective counter-model to the current one.

Despite this, we can see the hazy basis for new consensus forming on services and service trends.  At least one new service is visible in each of our categories.

In the area of evolution of Internet experience, there are two attractive service options developing; “transactional” VPNs and media “microstreams”.

A standard VPN exists for a period of time greater than minutes, and involves more than two sites.  A transactional VPN exists for the duration of a single transaction, and involves only the sites used in the transaction—usually, two.  All e-commerce activity involves transactions, and all of that activity is subject to enhancement through the mechanism of transactional VPNs.

How much money is involved in this kind of thing?  We estimate that there is already in excess of  two billion dollars of revenue opportunity in these transactional VPNs, and the opportunity would grow were the public to further commit to things like online shopping, brokerage, and banking.

Transactional VPNs differ from standard VPNs primarily in the fact that they require a very fast setup, based not on a pre-provision command (a management system or even a human customer service rep would normally create one ahead of time) but on the sensing of the transaction request at either the client or server end.  They also typically exchange a small amount of data, so one would think that the process of creating one might involve more resources than the actual transaction they support.

Today, transactional VPNs would have to be established through the use of something like RSVP, which features an exchange of a PATH and RESV command at initiation, and every 30 seconds thereafter.  This would clearly generate more overhead than many of the transactions it supported.

One alternative is to provide a form of RSVP with a variable reservation time—a “set up a path for x seconds” approach—but that would defeat the whole issue that RSVP’s timed renewal was designed to address, the possibility that router table changes would move the traffic away from the route where resources had been reserved.  In truth, though, most failures inside public IP networks probably would result in congestion to the point where any resource guarantees were meaningless, and the increased use of ATM or MPLS as an underlayment to standard routing would tend to create networks where route divergence would be unlikely in any case.  Thus, this seems a logical measure to adopt.

Transactional protocols like TTCP might also be employed.  TTCP is a shorthand version of TCP that reduces the overhead associated with session setup, also reducing time and traffic.  It might be possible to link TTCP with expedited delivery, but that would require network elements to be sensitive to transport-layer headers.  Some IP-heads dismiss this, but the truth is that RSVP requires the same kind of “sensitivity” or it wouldn’t be able to isolate the flow to be expedited.

Performance-wise, we can expect that transactional VPNs require relatively little bandwidth; their primary objective would be to control delay and delay jitter.  Thus, they are very strong candidates for what could be called “conduit bypass”, where a path is created around the Internet for a period of time to support a relationship in a unique way.

A variant on transactional VPNs would be software update downloads or other types of “commercial” downloads.  These would require a longer period of activation or a higher effective bandwidth, because the presumption is that a file megabytes in size is being exchanged.  The file could be software, music, video, etc., but the assumption is that if it is one of the latter two, it’s being stored for playing and not played in real time.

It would appear that these variants on the transactional VPN theme would be handled efficiently by the current protocols, with a single exception.  When we bypass the standard multi-hop handling of the Internet, we eliminate the value of TCP accommodations like slow-start, designed to prevent congestion collapses arising out of retransmission of lost data when massive numbers of sessions are concurrently lost due to network conditions.  There are already proprietary Level 4 procedures designed to eliminate slow-start behavior, and these would be good candidates for adoption if conduit bypass became a commonplace thing.

It may well be that the best answer for supporting transactional VPNs would be the TOS bits and DiffServ, but this solution would have to evolve into a more Internet-wide phenomena before it could be applied.  TOS and conduit bypass will clearly compete with each other, and which would develop would depend on the pace at which Internet QoS harmonized across the ISP space, and where buyer willingness to pay for premium transaction handling developed.  It might be that conduit bypass would be an early solution, that TOS/DiffServ would evolve as a broad-based solution if demand grew extensively, but that conduit bypass would remain viable for out-of-the-mainstream transaction requirements.

Our next item, the media microstream, is a small real-time file (something that lasts minutes) played to the consumer as a part of the website visit, and designed to promote the product or attract users to the site.  Since audio delivery in this context isn’t rocket science, we think most will be a form of video.

Media microstreams, unlike transactional VPNs, require both a significant amount of bandwidth and an extraordinary stability of performance, because they are targeted at delivering real-time media of some sort.  Unlike conference audio and video, which persist for a period of time and are probably not linked with the normal web behavior, media microstreams are likely to involve some web-integrated premium video or audio files that the sender or receiver is paying extra to have delivered in good listening/watching shape.

RTP looks like a good candidate for delivery of this kind of data, though conduit bypass of the Internet may also be useful if the value of the microstream is high enough.  We believe that the microstream concept would become prevalent enough to justify having its support included in baseline Internet services.  It’s likely that the use of the TOS bits to tag these streams for special handling would work.

In the area of displacing private network behaviors, the big issue is the impact of universal broadband access on the multi-company business, since there are few private networks that operate on an inter-company basis.  Is universal broadband going to accelerate the change from private networking?  Is the acceleration going to be limited to interest in arbitrage of usage-independent Internet services to displace low-quality private networking (no revenue stream to the providers)?  What would emerge as the key application set?

Telecommuting seems the likely driver in this space.  Existing applications support fixed-site workplaces not mobile or home workers, in the main.  An explosion in broadband access would  certainly allow companies to consider extending some core applications to their workers at home.  Some activities, like customer care and order-taking, are ideal for home work because call center management procedures would allow employers to determine if a home worker was slacking off at the pool, etc.

These applications, which effectively make a home worker the communications equivalent of someone sitting at a desk in the office, have implications in terms of service coordination.  Private networks aren’t generally IP-based today, though that is changing fairly quickly.  Broad-based public digital access could accelerate the shift to IP, which would accelerate the adoption of VPNs to replace private networks, because most companies probably wouldn’t re-capitalize their private networks in the face of technology changes.

A drive to convert private networks to IP would have the greatest impact on MPLS, which is already becoming a hot infrastructure standard because of its ability to form a kind of universal transport layer between the ever-diverging infrastructure and the service networks of the future.  MPLS offers circuit-like QoS and security, and while neither is a requirement in the majority of applications that will build public data revenues in the long term, both are requirements for private network conversion.

The final area is creating new business-to-business behaviors, and there we think the killer application is video collaboration.  Most private networks can’t afford to deploy enough residual capacity to absorb video conference requirements incrementally to their normal applications.  Having this stuff bypass the private network and be supported on a VPN would make sense, and the availability of universal broadband access would reduce the cost of having all the sites in the company (and even its persistent and valuable telecommuters) equipped with the correct facilities.

Unfortunately, bandwidth doesn’t solve video problems, as anyone who’s ever looked at real-time Internet video knows too well.  If the round-trip delay on video/audio gets much above 150 ms, the delay is likely to interfere with the interpersonal dynamics of the meeting itself.

Delay performance on the Internet varies considerably over time, and also depends on the exact nature of the relationship between the ISPs involved in supporting a call.  We’ve found that, on the average, we can keep delay to less than 150 ms on even transcontinental connections.  Internationally, all bets are off.

Existing protocols appear satisfactory for dealing with this application in general, but prospective video users need to realize that a reasonably high level of security is required in authenticating prospective attendees of conferences, to prevent video-based spying.  There is also a risk that someone’s behavior will get out of line, exposing the company to legal risk.  In short, widespread use of video may pose more legal/cultural problems than technical ones, other than the obvious question of willingness to pay.

Conclusion

Well, there we have it.  Near-term, at least, broadband networks will depend on application revenues derived from activities not too distant from today’s activities, and not too taxing on the current protocol sets.

Longer term, of course, this won’t be the case.  As network bandwidth cost plummets under the pressure of optical advances, two important bandwidth/price metrics fall.  The first is bandwidth economy of scale.  As networks get cheaper, the difference between the unit cost of bandwidth on a fat pipe and the cost of a dedicated skinny pipe decline to the point where concentration of traffic to achieve economy of scale isn’t capital-efficient.  Further, the distance-cost gradient of bandwidth also falls, which largely eliminates the benefit of caching and other technologies designed to exploit the difference between short-haul and long-haul transport costs.

As networks become more optical, in short, they become more a mesh of service devices with static topologies.  The process of “discovery” ceases to be of value.  Most of the protocols in use today are designed to conserve bandwidth; that isn’t necessary.  Discovery protocols won’t be necessary either.  By the time we’re done with this process, we’ve eliminated most of the features of the lower-layer protocols like IP.  Couple that with the fact that higher-level facilities like TCP’s slow start are likewise unnecessary, and we see a complete restructuring of the service protocols.

In the long run, it may be that the way this gets achieved is at the point of migration between IPv4 and IPv6, or whatever becomes the next version of IP.  If the “service protocol” of the future is linked to IPv4 clients through a gateway, we can adapt the mechanisms of that protocol freely without impacting the users’ applications or devices.

The changes in the access network that we’ll see beginning later this year will launch us on a new broadband-driven period, a period when many of the sacred cows of networking will fall.  IP, as we know it, will be among them.  Most of today’s applications will likewise become unimportant.

Strategies

Lucent has submitted a VPN response that's both conformant to the structure and style of our VPN objectives article in the September, 1999, issue, and insightful.  Sorry, but it's for subscribers only!

Down the Line

Next month, we’ll present some of the details of the RBOCs’ plans for ATM-based access.  We’ll continue our VPN vendor submissions a bit longer this spring, then publish the entire group and our three-part “requirements” piece as a PDF.