The talk about Level 3 and Level 4 switching is probably giving most network managers a headache. The concepts both seem to promise a relief from the rigidity and performance limitations of routing, but many users have found that introducing either type of switching may make no difference whatsoever in network performance. What's a planner or manager to do?

The problem we have with switching today arises largely from the desire of vendors to promote switching as an easy, step-wise, evolution from traditional routed, shared-media LANs. Under the "easy migration" paradigm, users simply stick switches into the network wherever there's a congestion problem or a need for speed, and the network does better. That simple paradigm isn't always valid.

Networks have two structures that must be considered in information movement. One is the physical structure of the network – the wiring plan or topology. The other is the logical structure of the network, as imposed by the address plan used for every protocol at Level 3. The interplay of these structures controls information movement.

In traditional routed networks, shared-media LAN segments (including hubbed 10/100BaseT stuff) form Level 2 subnets. Each of these subnets has a domain of users that can be reached locally at Level 2 (the subnet's own membership, as determined by the subnet mask used to define the subnet's address space), and each has a default router address through which the subnet members reach partners not in their subnet.

In most networks, this default router is the wired-in upstream link for the shared-media LAN. The LAN segments at Level 2 fan out from this default router. Higher-level backbone networks gather these first-level routers in, creating a multi-tiered structure that looks like an organization chart.

What is interesting about this structure is that the logical address structure of the network – the subnet structure and the default router concept – are most often designed around the physical topology.

We build and wire a network. This creates "nexus" points where multiple components at one level have to combine to reach the next. At these nexus points, we install a device that can do the combining and routing between the lower-level components. We then assign addresses to reflect the physical structure we've built.

That's where switching strategies start off down the long, dark, road. When we install switches, we put them into the same topology matrix that we had non-switched devices. These switches, if used with the same address structure and same physical topology, inherit the same mission as the devices (routers, for example) they replace.

So what? If switches are faster, won't the network go faster even if we don't improve its structure? In fact, it won't. Most networks today are limited by their media or circuit performance, and not by the performance of the devices. If you have a router capable of handling 100k packets per second, that equates to a bit over 51 megabits. Such a router, with four input ports and one output port operating at 10BaseT speeds, is capable of filling all the pipes. The network is media-bound. On the other hand, using 100Base LAN connections would require more capacity than the router provides in order to fill the pipes, and so such a network would benefit from switching.

Most routers today have more than enough capacity to support the trunks already in use, and thus there would be no benefit to upgrading them to switches – unless there were some other benefit we could derive.

There is – if we do our switch planning correctly.

Let's go back to a simple network. Imagine one "king router" at the top which we'll label "A". That router talks to two second-tier routers ("B" and "C"). Router "B" talks to two hubs, labeled "D" and "E", and router "C" talks to two more hubs, "F" and "G". Got the picture?

In a classical address management scenario, each of the hubs represents a subnet, and the lower-level routers are their default gateways. A user on Subnet "D" would talk to one on Subnet "E" by moving through the router "B". A user on Subnet "E" would talk to a user on Subnet "G" by moving from "B" to "A" to "C".

Now we stick switches in to replace all the routers and hubs. We assume that the switches replacing the hubs are Level 2 switches, and those replacing the routers are running at Level 3. What happens to our information flow? Nothing. The same connection structure exists, and the same address structure, too. If the switches can't fill the pipes better, there's no performance difference.

Now, imagine that all the switches are Level 3-capable. Again, no difference, necessarily. The switches at the bottom tier ("D" through "G") don't have a level 3 mission given the address structure of the network – they support a single subnet.

If a user in Subnet "G" were to move to sit on Switch "D" in our new scenario, we'd use the VLAN property of switches to support that user as though he continued to be on switch "G"; he wouldn't change his Level 3 address or subnet just because he moved. But because of this, his data path to his partner user on Subnet "D" would be really circuitous:

1. First, the user would address his default gateway at Level 3 (switch "C") to reach an off-subnet partner. This request would move from the repositioned user to Switch "B" at level 2 in a VLAN link, move through switch "A", and on to Switch "C".
2. Second, the data would move at Level 3 from the default gateway to the destination LAN segment (now a VLAN): switch "C" to Switch "A" to Switch "B".
3. Finally, the data would move from switch "B" to Switch "D" at Level 2, to reach the user.

All of this would happen even if the user from Subnet "G" moved to the very next port on Switch "D" used by his partner .

How to make this better? Recognize that what we're doing here is what traditional structured networks have to do: move data to the point where address processing at the needed level is available. The better strategy in a switched network is to move address processing to where the data flow would optimally go .

How does that work? What happens is that every switch in our network is now made Level 3 aware, but one switch (probably Switch "A") contains the full address knowledge of the network. Now what happens in the case of our move is this:

1. The source user (the one who moved) sends the data to his default gateway as before.
2. Switch "D", the one the user is connected to, intercepts this default gateway request and makes an address resolution request upstream to Switch "A".
3. Switch "A" responds that the destination user is available on the adjacent port of Switch "D", and is reachable at Level 3.
4. Switch "D" follows the Level 3 procedure (ARP, etc.) to find the destination user and deliver the packet without any handling by any other switch.

This type of distributed Level 3 functionality is the key to the maximization of the benefits of Level 3 switching. Without it, there is a good chance that the substitution of Level 3 switches for traditional LAN switches at Level 2, or for routers, will provide little benefit.

How about Level 4 switching? First of all, the concept of network nodes handling Level 4 is a kind of OSI oxymoron; there is no Level 4 processing in transit network nodes by definition of the OSI model of networking. What is it, then?

Most vendors use the term "Level 4 switching" to indicate that the transit switches have some awareness of end-to-end flows. The objective of this awareness is to allow the switches to handle the flows according to user priorities. In particular, the concept would allow resources to be allocated on a per-flow basis so that higher-priority applications would receive a larger share of resources.

The problem here is twofold. First, where exactly are these congested resources that have to be allocated, with respect to typical user flows of information? Second, how is a priority system administered?

The first issue is particularly significant these days, given the fact that LAN switching costs are falling so sharply. Today, the price per port for a 10BaseT switch port is less than $80 from a host of vendors. At that low a price, it is doubtful whether complex schemes for resource allocation would be useful, since the cost of resources is low enough to permit oversupply – at least on the LAN.

In the WAN, where resources are scarce, it is clear that we'd have to allocate resources according to application priority. It is also clear that the LAN doesn't necessarily have to figure in the process. The device at the WAN DMARK could signal to the traffic-generating station to limit exit flow to the value that could be passed over the WAN, based on application priority. If the intermediary LAN devices are not themselves subject to congestion, then no other switches need be involved. Signaling like that provided in RSVP could be used to communicate with PC driver software, telling that software to shape traffic according to the combination of WAN needs and installation priority.

Within a WAN cloud, it's clear that resources have to be allocated according to application priority – which, in carrier networks, will be based on how much users pay for transport. Premium services have to experience premium service. But however this is done, and no matter how complex the implementation, it doesn't have to impact LAN switching at all. The DMARK is the service boundary between customer and carrier, and that device is a service agent to the service set projected by the carrier. As long as the agent knows how to enforce the rules at the edge, it doesn't have to know why the rules exist.

To summarize, Level 3 switching is useful if the vendor provides it in a way that allows switching decisions to be made by the devices along the shortest path between source and destination, rather than through the process of sending data to the decision points. This has major implications on switch design, exposing issues that switches are not rated on today at all. Level 4 switching is probably an issue for inside WAN clouds and not a rightful issue at the LAN level at all.

Many of the market dilemmas created today are created not by a real issue set but by improper promotion or incomplete understanding. For the busy manager, the best decisions may not be the ones that seem to be supported by popular wisdom. Choose wisely.

There are many frustrating things about networking, but perhaps none so frustrating as the tendency of the industry to develop new terms that aren't particularly descriptive. It's worse when the terms contain common words – words that imply a connection between concepts but don't make clear just what that connection is.

A group of users we were teaching recently had a complaint about one such word: proxy . We have "proxy agents", "proxy processes", "proxy ARP", "proxy clients", and more, said the group. Are these related concepts?

Well, they are and they aren't (thought this would be easy, didn't you?) at the level of the complete term or phrase, but they are definitely related in the sense that the term "proxy" has a common meaning. In fact, proxies are a key element of many networking products and architectures.

A proxy is a stand-in, according to the classical definition. It's something that substitutes for a component or individual. In stockholder meetings, for example, shareholders are offered the opportunity to attend, or to execute a proxy to allow someone to vote their shares in their absence.

In networking, the term has been adopted to describe a whole series of software elements or hardware devices that "stand in" for another device. Usually, this stand-in process is not intended to provide the full functions of the other device, but rather to emulate some of that other device's functions so as to fill a specialized network mission.

Let's look at a simple example: proxy ARP. The process of address resolution in TCP/IP LANs must reflect the fact that on a LAN segment, stations are reached by their media address, but in a router the Level 3 or IP address is used. Since applications know the IP address, they have to find out what media address (MAC-layer address) a given IP address is associated with if the IP address happens to represent a user on their own LAN segment. This is done by issuing an ARP – an Address Resolution Protocol request – as a media multicast message, asking the station who owns a specified IP address to respond with their MAC-layer address.

In early UNIX TCP networks, it was popular to have remote connections to a LAN using a single dial-in modem. Companies like Telebit made these modem products. It's easy to see how a modem could be connected to a LAN, but hard to see how the modem would know to dial the remote user if somebody sent a message. Why? Because without the remote user being available on the LAN , there would be nobody to respond to the ARP message with that user's address, and a partner station would never direct any message to the user at all.

But suppose the modem on the LAN "stood in" for the user? If the modem answered the ARP as though it were the user, it could then use that ARP as a signal to dial the remote system to make the connection. The remote user's local partner, in the meantime, would send the data message to what it thought was the user, but in reality the data would go to the user's modem proxy on the LAN. That proxy would then forward the data to the remote user over the modem connection. Success!

Proxy ARP isn't the sort of thing you'll see much of in commercial networking, however. The model of TCP/IP networking most commonly used in business is the "LIS model", where "LIS" means "local (or logical) independent subnet". In this model, all of the stations on a LAN segment are assumed to be local, and any station that has to be reached via another trunk or phone connection is assumed to be in another segment, and reached through the default gateway router. But while proxy ARP may be rare (and so, in fact, is Telebit), the proxy concept remains strong.

A common use of a proxy is the network management process. Today's LAN internetworks are most often managed by the Simple Network Management Protocol, or SNMP. SNMP is a master-slave protocol that allows a management center to command a device agent to either read variables in the device agent's management information base (MIB), or set values there. The agent sits dumbly in the network waiting for somebody to either read or set something – which means that it is a polled interface.

This polled relationship has some real shortcomings. Because changes in device status can't be detected unless the management system reads the device MIB variables, management systems are prone to go out and poll these MIBs on a fairly regular basis. If there are a zillion devices in the network, there are a zillion devices to poll. Most of the time, the poll of device status will result in the agent equivalent of the "nothing much going on here, boss" response, which means that the network traffic generated by this process (which can be considerable if there are a zillion devices) accomplishes nothing but interferes with real data flows.

One way to solve this problem (incorporated in the OSI Common Management Information Protocol and proposed in revisions to SNMP) would be to allow the device agent to report without being polled – the "alert" model. Another way is to use a proxy agent .

Let's assume that we have a big internetwork of a thousand LANs. We could install, on each LAN, a software component that "looked" like a management center software element. This management center could poll all of the local devices and find out if anything had changed. But instead of really being a management center, this software component would be a part of our proxy agent. The change/no-change knowledge would be stored in a pseudo-MIB, using a variable name like "MY_LAN_CHANGED". This MIB with one variable is now made visible to the real management system, because the proxy agent "looks" to the real management system like another device. The proxy agent is thus double-jointed, with a "downstream" appearance of a management center, and an "upstream" appearance of a device MIB.

Now, instead of polling every device on the LANs, the management center polls only the LAN proxy agents. If it finds an agent reporting MY_LAN_CHANGED, it polls the subsidiary devices in the LAN to find out what's happening there. If there are a hundred devices in each LAN, this reduces the number of polls needed to check everything from 100,000 to 1,000 – a big difference in traffic.

Proxy agents can also be used to create a virtual network component to represent an important set of relationships. If the connection for issuing paychecks must go from Host A through Switch B through Router C to Printer D, we could use a proxy agent to check the status of all these devices, and if any reports a problem, the agent could set a variable called "NO_PAYCHECKS". There is, in fact, no device that has such a variable, but the management system (and, for sure, the operators) now have a direct way of knowing whether paycheck issuing has been compromised.

The proxy agent example shows that a proxy is often two different software elements back-to-back, with a special process connecting them. Each element plays a role in a specific network relationship, emulating something "real" that would ordinarily play that role. In the proxy agent, the real things were the management center and the device agent/MIB.

The same principle can be used to develop a protocol converter or emulator. In fact, such functions can nearly always be viewed as proxies. If I wanted to make a TCP-to-APPC converter to allow a Windows Sockets application to talk with an IBM Advanced Program-to-Program Communications mainframe application, I could use a proxy to do it.

To build a converter proxy, I first have to create two components, each of which talks the language of the protocol world they'll connect to. For the example, I'd need a TCP/IP protocol stack and an SNA/APPC/LU6.2 protocol stack. These two stacks would take care of all of the specialized protocol conditions in each of the two networks, doing error recovery, flow control, and so forth. The effect of the stacks would be to extract the real data – the user information – from the protocol context of its delivery.

To make a protocol converter, I must now glue these stacks together. That seems easy: take data from one stack's output and stick it into the other stack's input. In real life it's more complex. There are error conditions (like "destination not available") that may be detected by the lower-level protocols. Those conditions must be somehow mapped between the two protocol stacks, even though it's likely that the exact same condition won't exist in both of the two protocol worlds.

We can summarize the function of a converter proxy as follows:

• Satisfy the protocol requirements at all protocol layers used, in each of the networks involved.
• Isolate the data component of the protocol and make any changes in information coding or format required.
• Pass the data between the two networks using the appropriate protocol stacks.
• Receive any error conditions the lower protocol layers couldn't correct, and translate them to conditions meaningful in the other network.
• Request outside intervention if any condition arises that cannot be readily translated from one network to another.

The success of conversion proxies depend on their being a high correspondence between the data services offered in the two networks involved. For example, if a proxy were to be asked to link data between a connection-oriented and a connectionless network, the proxy would have to simulate connectionless and connection-oriented services in the respective networks, a much larger task than simply pumping data between two protocol stacks.

Proxies also have to resolve any addressing issues in the two networks. A proxy performing a conversion function is normally associated with a directory that provides cross-matching between the addresses used to represent users in each network's address space.

The proxy conversion concept is clearly illustrated in the so-called "proxy clients" used in ATM's LAN Emulation (LANE) and Multi-Protocol Over ATM (MPOA). Both LANE and MPOA provide a means for ATM-equipped stations to communicate with each other using LAN protocols – essential if LAN applications are to be used by ATM desktop users. But each must also allow ATM users to communicate with legacy LAN users. For that mission, both turn to the proxy.

The LANE procedure is easiest to understand. A LANE proxy is a LAN device, usually a bridge or router, who talks whatever standard LAN Level 2 (MAC/LLC) protocol is in use by the legacy systems. The same device also implements the function of LAN emulation that would ordinarily be supported in an ATM desktop adapter.

In operation, the proxy client uses software to make its collection of legacy users appear to the ATM world as a series of ATM-equipped desktops. The proxy client registers all of its legacy users' addresses with the LANE address resolution process, assigning them ATM addresses for the registration. This means that when another ATM desktop asks for the ATM address of a LAN partner that happens to be on a real LAN "behind" the LANE proxy client, the server will return an ATM address to a process on the proxy client. That process will then address the data to the "real" user on the LAN.

The same thing works in the other direction. When a legacy station tries to communicate with an ATM desktop, the proxy client serving as the legacy station's gateway to the ATM network will go to the LANE server and get the ATM address associated with the LAN address the real station provided. The proxy will then set up an ATM SVC to the ATM desktop, and will shuttle packets between that SVC and the real LAN segment on which the source user is found.

When two proxy clients are talking together, they might elect not to bother with isolating each of their users' conversations on individual SVCs, but rather to "gang" everything on one SVC between the two proxies. This is allowed in the current version of LANE, which supports the use of standard SAP encapsulation of the type used in bridge/router products to identify the specific LAN address a given message belongs to. SAP encapsulation of proxy-to-proxy traffic reduces virtual circuit overhead and handling, and is a feature in WAN-based ATM proxy products like Newbridge's Carrier-Scale Internetworking (CSI) product set.

In theory, a proxy can be used for any "active" protocol component in a network, though in practice some components don't make sense to proxy. For example, proxying a real client or server would mean you'd have to invent or discard data, since the function of computation and storage, or the function of human analysis, is likely to be beyond the scope of simple proxy processes. There are some areas where proxies are already gaining favor.

In ATM's Available Bit Rate service (ABR), a special cell is circulated between source and destination to carry the current bandwidth availability information to the network's consumers. But this process requires that the end applications be aware of ABR service and respond to these cells. Today's applications do not. Thus, a proxy function must be used to link ABR to non-aware applications.

An ABR proxy is a traffic shaping process (like a big buffer). The real application throws its traffic into the buffer, where it waits for transport. The traffic is removed from the buffer by the proxy according to the amount of bandwidth the ABR cells tell the proxy can be consumed. When the network has a lot of available bandwidth, traffic is pulled from the buffer rapidly. When it doesn't, the traffic exits the buffer more slowly. The buffer replaces the application in handling the ABR exchanges, and the proxy brings ABR benefits to the application that could otherwise not consume ABR services.

Another example of a proxy application gaining support in the marketplace is the RSVP proxy . The RSVP protocol was designed to allow applications to reserve specific QoS over connectionless networks. It works by having an application that can supply data (a server) issue a PATH message describing the characteristics of the flow it would generate. A client subscribing to that flow would generate a RESV message in response, and the intermediate network elements would examine the flow specification to insure they could meet the requirements of the flow when it began.

A great theory, but one practical problem is that there aren't any RSVP-aware applications to speak of. Servers don't generate PATHs, and clients wouldn't know how to RESV a PATH if they received such a message. Thus, the concept fails.

Proxy to the rescue! An RSVP proxy sitting at the switch port could generate PATHs to advertise server flow availability, and another at the client side would be able to issue the necessary RESV to join the flow and commit the resources.

But the RSVP proxy illustrates the problem of "intervention by a higher level" we touched on earlier. The problem here is that a proxy doesn't know that a server has a flow to propagate, nor does it know whether a client wants to accept it. Neither proxy, were they aware of the relationship, would know what flow specification was associated with the flow.

This is where policy management servers come in. The RSVP proxy is given a list of addresses that represent available sources and participating clients, and a value for the resource guarantee each combination of source/client is to be given. When a client and a source start talking, the proxy quickly exchanges the PATH/RESV with its partner proxy to establish the resource link through the network. The client and server go about their business happily unaware that proxies are assuring their traffic quality, and insulated from the message set involved in gaining and maintaining that assured path.

It should be clear by now that proxies may be a key to the future of networking. The biggest problem with the advance of technology is the inertia of the installed base of hardware and software. If the thing we are trying to service is an old application, how can we bring new network features to it? The application, rooted in the past, can't participate in the future. If we are trying to add a new technology to a network, how can it interconnect with a technology that never anticipated its partner's features?

The answer is "Through proxies". The systems and devices we buy in the future will depend increasingly on proxy functions to link modern service network technology to legacy network components and legacy applications. Through the agency of proxies, we'll be able to bring improvements to networking and still contain the scope of the impact, without containing the scope of the benefits. That's a key to the financial success of any networking process.

Yet is the proxy, for all its value, just a transition aid? Will ABR be successful if there is never an ATM-aware application written? Can SNMP proxies be truly useful if there is never any attempt to pull their benefits into the SNMP standard itself? We've chosen these two questions for a reason: one seems to be answered in the affirmative and the other in the negative. It appears that ATM networking would benefit from ABR whether we ever have an ABR application or not. But it appears that the need for SNMP proxy agents, at least in the poll management sense, will ultimately be undermined by evolution within SNMP itself.

The truth is that the proxy balances the old and the new. We have assumed that the pace of progress inevitably destroys the artifacts of the past, but it is clear that in technology that is not the case. We use PCs today that have inherited an architecture from a 1981 model so primitive it came with a standard cassette tape interface. The sudden surge in sales of the IBM PC made compatibility with the installed base mandatory, and that froze the architecture in time. We've tweaked it a bit, but that old 5150 Model still shines through.

Progress means "advance", and the thing we have to measure "advance" in technology is not just the arrow of time, but the arrow of benefit. We'll probably always have places where the peculiar combination of factors that led to a given technology's popularity will give rise to an architecture just too expensive to change.

Don't worry. Proxies will be there to save us.

One of the things that happens when someone raises a network topic that excites everybody, is that nobody seems to want to examine the issues really carefully. It's as though we believe that somehow we'll find something that will make our dreams vanish.

Reality is that vanishing dreams are most likely to be associated with network issues that don't get examined thoroughly. The sad truth is that most of the exciting stuff needs some real help coming true, and ignorance of the issues isn't a very good way to get that help.

High-speed, "always-on" Internet access is a good example of an exciting topic that's not being covered with much insight. Most of us would like to believe that we'll somehow get megabits for mini-bucks. If it's possible for that to happen, though, we'll have to understand the technical and business metrics involved.

To provide always-on, high-performance Internet connections, we have to dispense with the whole analog modem dial-up process. That means that we'll need to deal with all of the following:

• PC client software will have to recognize an Internet connection that we don't dial (via Windows 95 Dial-up Networking, for example). Fortunately, that's pretty much a matter of reconfiguring the browser to expect a connection to be there all the time, rather than to dial one.
• We'll need hardware. In theory, a PC could support an always-on connection up to about 240 kbps via the serial port. Faster than that, and a special hardware connection will be required. Most people think that fast Internet connections will be made via a LAN adapter.
• We have to consider the interaction between our new Internet connection and any full-time LAN connections we already have on the system. Dial-up networking creates a TCP/IP connection that is bound directly to the browser. If we use a LAN adapter to get to our Internet service, we may have a risk of exposing our LAN resources to the Internet. We may also have address collisions between us and the Internet if we've adopted some private IP numbering plan internally.

OK, so we can make a fast connection from our end. What do we connect to? Users have a lot of latitude in networking, but creating extemporaneous carrier service connections isn't one of the things we can expect to do. Fast Internet service will have to be offered by somebody. In fact, there may be several "somebodies" involved in a typical Internet connection. There are also several ways in which the connection can be created.

Let's do jurisdictions first. In the US, we have a class of carrier called a "Local Exchange Carrier" or LEC, who provides the link between our business or residence and a serving carrier office location. There, our voice or data traffic is distributed to other offices, and eventually to the human or computer modem we call. While LECs may be providers of Internet services, most of us get our service from somebody else.

That somebody else is an Internet Service Provider or ISP. The ISP provides some local mechanism for collecting Internet connections, and then aggregates the traffic for delivery to the Internet itself. This process of delivery may involve a direct linkage to a major Internet concentration point (a Network Access Point, or NAP, or a Metropolitan Area Exchange, or MAE). The ISP may also link to a kind of super-ISP who provides this Internet linkage. MCI and UUNET are popular super-ISPs.

OK, now, to get a fast and permanent connection to the Internet, we must first get a fast and permanent link between our business or residence and the ISP. This is normally done through the LEC, and the LEC has a number of technology choices:

1. A traditional leased line, which has no usage charge and no dialing. Leased lines can be had starting (usually) at 56 kbps and moving upward as far as your bankbook will let you go. Business users of the Internet normally obtain their fast and permanent connections this way.
2. An ISDN connection that stays "off-hook" all the time. This provides either 56/64 kbps or 112/128 kbps access, depending on whether the channel loses bits to signaling and whether one or both ISDN B channels are used. The value of ISDN versus a leased line depends on pricing.
3. Digital subscriber loop technology – xDSL. This isn't so much a new kind of link, as a new way to create an old-fashioned leased line. If it's cheaper to provision a connection with xDSL than with the traditional technologies of leased lines, xDSL is more attractive to buyers.

People other than the LEC can be providers of high-speed Internet service, too. Some of the likely non-LEC providers are:

• Cable companies. Cable modems for Internet access are already deploying in many locations, and offer Internet services at rates ranging to nearly 1 million bits per second.
• Satellite providers, who offer a fast inbound channel via satellite and a slower user-to-Internet channel via a more traditional network technology. DirectPC is an example of this.
• Local microwave providers, who can use either unlicensed or licensed microwave to provide an ISP-to-you connection at a fairly high speed. Some present or future players here will be offering LAN-speed access.

Non-traditional players like the ISPs themselves, or public utilities, could also use any of the LEC or non-LEC technologies mentioned to provide a connection.

Whoever you get to provide the connection, the connection is going to cost money. Leased lines run between about $150 per month and thousands per month, depending on both the speed of the connection and the distance it runs. Normally, leased lines are charged by mile from source to destination. Other service types range in cost from about $75 per month up to several hundred per month.

The access connection isn't the end of the paying, either. In many cases, the next guy with his hand out will be the ISP. When an access line terminates at an ISP point of presence (POP), the terminating connection is called a "port". The ISP will have to pay to add that port to some sort of device – an access server, a switch, or a router. The cost of that hardware is part of your fast Internet cost.

The ISP has other costs, too. Buying a megabit of Internet access means putting greater load on the ISP's own network, and on his connection to the real Internet. The cost of providing bandwidth and equipment to support this greater load is also going to be paid – by you.

How much is that? Today, the average cost for a T1 port on an ISP is just a tad under $2,100 per month! What that means is that the least a fast Internet connection could cost, even if we made some fancy DSL strategy free , would be $2,100 per month.

Whoa! Nobody would pay that! Does that mean that the whole cable modem or xDSL play is a hoax? Partly, to be sure, but there are other factors involved.

It's a hard truth that the T1 port to the ISP is going to cost two grand, gang. The only way, therefore, that we can make our service affordable is to make a bunch of users share that port. If we had 20 users on the port sharing the cost, we've gotten prices down to about a hundred dollars per month. Get a hundred users to share, and costs are now around twenty dollars.

Sharing is the key – and the problem.

If we have a bunch of users sharing the same T1 ISP port, we can envision a number of modes of service:

• All the users could have relatively light use of the Internet. In this case, they would not collide with each other often, and each would seem to be enjoying the full benefit of that T1 bandwidth. This is what we'd like to see happen.
• All the users could be beating the bits like a musher flogs a dog team. In this case, everybody is trying to get the full T1, and what each gets is one-nth the T1, where n is the number of people sharing. Here, everybody is mildly to seriously annoyed, depending on just how crummy the resulting performance is with respect to what buyers expected for their money.
• Some of the users are sharing nice and the others are hogging mercilessly. This is what happens on the Internet dial ports today, and what will probably happen with high-speed access. Over a third of the Internet's resources today are consumed by less than 10% of the users. The rest subsidize these over-achievers.

Generally, people believe that most users won't opt for high-speed access just to subsidize someone else. Thus, though attitudes would be expected to promote our third model, complaints from the givers (as opposed to the receivers) would be likely to stifle the growth of the high-speed services.

The model doesn't have to be left to chance, however. Every fast-Internet subscriber will have to connect to something that multiplexes his traffic with the others who are sharing the cost of that T1 port. This device can regulate just how much bandwidth a given user gets, directly or indirectly.

Direct regulation means having some kind of "bit governor" that would limit the amount of the port capacity a given user could secure. The mechanism would probably be complex, but the result would be that no one user could hog the connection to the disadvantage of the others.

Indirect regulation is less complex in principle. Charge by the packet and let the wallet decide. This way, a hog user pays more, and the service provider can thus have that user share with fewer companions. This makes the service more fair, but the problems of collecting statistics to bill turn out to be as bad as the problems associated with regulating the flows.

There's another option, of course: subsidization. If somebody wants to pay for a subscriber's high-speed connection (in the whole or in part), the subscriber's own burden is lifted. Who wants to do that? There are a lot of suggestions, from the government to big business. The most rational one is the latter.

Content providers, sellers of goods, and other people with a financial interest are what really make the Internet. We'd like to think of the Internet as a world cultural resource, but it's really a big electronic on-demand space ad. The only mission that can really assure the future of the Internet is the mission of commerce. Here we don't mean the relatively minor task of completing a transaction (on-Net credit card buying or other forms of what we think of as e-commerce), but rather the complex and vital task of bringing buyer and seller together and stimulating the exchange of goods and bucks.

Eventually, as the Internet matures, we will see both a willingness on the part of businesses to subsidize consumers on the Net, and a mechanism whereby that subsidization can take place. Our models show the beginning of this trend as about 1999, and the full maturation of the trend happening in about the year 2004.

Technology is the only thing anyone wants to talk about in the high-speed Internet space, but it is probably this business issue of subsidization that will determine just how many of us get fast Internet connections – and when.

In future issues, we'll take a look at the issue of high-speed Internet access in more detail. First, we'll look at the subsidization models and what will be required to validate them. Next, we'll look at how the popular contenders for subscriber access – cable modems and xDSL – measure up in the critical issue of "sharing management".

Access the index of CIMI Corporation's recent newsletters.