Cell Relay Archive

[Jonathan Turner <jst@cs.wustl.edu>]

Like many people, I have been disappointed in recent years at the
limited success that ATM technology has managed to achieve in
the commercial market. Recently, I've become convinced that
one of the reasons for this limited success is that the
industry chose exactly the wrong strategy for ATM
deployment into the global communications infrastructure.

At the start, many of us thought ATM could be introduced
as an end-to-end network technology, replacing
many of the existing technologies and integrating different
communication applications onto a single common foundation.
While this was a worthy goal, it was difficult to achieve
in the messy, complicated world of data networking.
In its attempt to find a place in the data networking world,
the ATM industry made a decision to position the technology
as a subnet technology that would operate under IP. This
decision was reflected in the development of LAN Emulation
and in ATM's current role in the backbone of ISP networks.

Unfortunately, by placing ATM in a subordinate role, the
industry largely discarded the improvements that ATM was
seeking to bring to communication networks. Since IP was
providing the network API, there was no way to introduce
QoS or other features, except on IP's terms. Given the
widespread hostility of the IP world toward ATM, this was
a little like the industry putting a gun to its head and
inviting the IP folks to pull the trigger. They've been
only too happy to oblige.

With hindsight, it's now easy to see that this was a poor
strategy. What's more, it's not hard to see how we might
have avoided the trap we fell into. Rather than subordinate
ATM to IP, we should have been using IP as a subnet technology
for carrying ATM traffic. As the new kid on the block, what
ATM needed more than anything, was a way of moving traffic
among scattered islands of ATM capability. Unfortunately,
the carriers never saw fit to provide a cost-effective and
useful ATM service. However, the carriers are not the only
game in town. Given the now ubiquitous nature of the Internet,
there is no fundamental reason why one cannot create
ATM virtual links through IP networks. These links will
be subject to the usual limitations of IP networks, but
at least they could provide connectivity, and there is some
possibility that an appropriately-designed gateway might
be able to implement virtual links through an IP network
that function enough like real physical links to provide
reasonable performance. Since IP networks are generally not
priced based on usage, this approach introduces no added
costs for organizations whose internet connections are
not fully utilized. It could even be cost-effective,
even for organizations that need to add bandwidth for
the purpose.

What might be achieved in this way? In the case of
Washington University, we have a 45 Mb/s connection to
the internet that generally operates at less than 50%
utilization, so one can reasonably imagine creating
several virtual ATM links from our campus to other
ATM sites with a bandwidth of say 5 Mb/s each. While
this is skimpy compared to the bandwidth we can support
within the campus, it's enough to be interesting, and
one can certainly envision increasing it, as higher
bandwidth internet connnections become available.
In fact, we have a second 45 Mb/s connection to the
vBNS that is very lightly used, so we could probably
get 2 or 3 additional 10 Mb/s virtual links as well.

How should one design a virtual ATM link, to get the best
possible performance from the commodity Internet?
One approach is to periodically transmit fixed-size IP
packets, containing space for say 10 cells each. Each cell
would have its own VPI/VCI, just like a real ATM link.
Cells would be packed into packets at the sending end
and unpacked at the receiver. Unused cell slots could
be filled with unassigned cells. Each packet would have
a seqeuence number, so that the receiving end could
monitor packet losses, and the receiving end could report
these back to the sender to allow the sender to make
rate adjustments. Rate adjustments should be relatively
slow. Since we are trying to emulate a physical link,
we don't want rates to change much. At the same time,
there is no point in attempting to send at 50 Mb/s through
a path that only has enough bandwidth for 10 Mb/s.
Of course, you can also use this technique within a campus
to create virtual ATM links to desktops using existing Ethernet
facilities. This is similar to the cells-in-frames approach
that has been around for sometime. 

I am purposely suggesting periodic transmission, even
if that means sending partially or even completely empty
packets. The purpose of this approach is to prevent
applications like TCP from increasing their transmission
rates to the point where they interfere with the
virtual ATM links. By keeping the virtual links busy
carrying packets, even when there are no cells, we improve
our chances of having the bandwidth available when we
do have cells to send. Although, such a virtual link is
clearly not the ideal tool for achieving end-to-end QoS,
I think you might well be able to achieve better QoS
through an end-to-end ATM connection that used virtual
links than through the commodity internet alone.

It may be too late to implement an ATM-over-IP strategy
(although it would be fun to try). On the other hand,
I think there is a general lesson here for introducing
new network technologies. If you hope to succeed as an
end-to-end technology, you can't do it by going underneath
the existing dominant technology. You have to bootstrap
on top of the existing technology. You have to use it to
go end-to-end. And you have to do the hard work of developing
and deploying applications that use your technology directly. 
This is how IP succeeded. It leveraged Ethernet and the telephone
network and offered some useful applications that gave people
a reason to use it. Any technology that hopes to displace
IP in the future, will need to follow IP's example. Use IP
to establish end-to-end connectivity and build applications
that provide something new and better than what IP has to
offer. If we are to move beyond IP in the years ahead,
this is the strategy that we will need to pursue.

Jon Turner