[net.dcom] General Purpose Communications Networks

jst@wucs.UUCP (Jon Turner) (09/21/85)

I've been interested for sometime in communications networks that are
designed to handle a wide range of different applications and would
like to start a discussion on this topic. I'm interested primarily
in large public networks rather than local nets.

Current networks tend to have a very strong application orientation
--telephone networks and CATV networks exemplify this statement.
Because the application is embedded so deeply in the network it's
very difficult to adapt these networks to other purposes. Data
communications networks are much more flexible, but the current crop
has a fairly limited performance range which makes them unsuitable for
many applications.

Currently, we handle diverse communications needs by implementing
multiple application-oriented networks. I feel that this approach
stifles the development of new applications, because if we can't hack
an existing network to do what we want (which is often the case) our
only alternative is to implement yet another network. I think this
approach is rapidly becoming unworkable--it's time to start thinking
about networks that separate applications from communication in a
way that makes it easy to develop new application. Such networks
must (1) provide a rich set of generally useful communications
capabilities and (2) do so at the highest possible performance level.

My own work in this area started in 1981 when I was at Bell Labs.
I worked with a group of people on what was called the Fast Packet
Network project, which had as its goal the development of a high
performance packet switching system suitable for both voice and
data communication on a large scale. We designed a system using
1.5 Mbs links with fast hardware protocol processors. The switching
was handled by a large binary routing network. We designed
packet switches large enough to carry the traffic of a typical
toll telephone switch and cost-competitive with circuit switching.
Packet switching was chosen for two reasons (1) transmission economies
and (2) the flexibility that it offers. The second reason is in my
opinion the important one. Packet switching allows one to provide
connections of arbitrary bandwidth which is difficult to do with
circuit switching.

I left Bell Labs about two years ago and am no longer up-to-date with
the work on FPN although I understand it is continuing. Early this
year I started looking into ways of extending the earlier work in
order to handle higher speed applications such as video. It turns out
that the speed-up required for video is not hard to obtain. Using
a combination of techniques it's possible to build packet switching
systems capable of handling 100 Mbs fiber optic communications links.
Custom protocol processors can be implemented on two chips using
1 micron CMOS. The switching fabric becomes somewhat more complex,
but the overall system complexity is still dominated by the protocol
processors. The more interesting extension required by applications
such as video is the need for multi-point connections. We want to
be able to set up a connection that can be used to distribute
a commercial television signal to possibly millions of receivers.
The idea is that someone establishes a broadcast source and then
other users send messages to the network asking to connect to
that source. The network then hooks them into the connection at
the nearest point. The switching systems take care of replicating
the signal as needed. The connection induces a tree
in the network spanning all the participating endpoints. The bandwidth
of the source can be any speed from a few bits per second to 100 Mbs.

We can generalize the simple broadcast connections to handle other
applications such as teleconferencing. In this sort of application
we have a multi-way broadcast or more appropriately, a broadcast
in which the role of the broadcast source is passed back and forth
among the different endpoints.

Although we've yet to build a prototype, we've studied the problem in
enough detail to be convinced that it can be practical (I'll be happy
to send a paper to anyone who's interested). There are however a lot
of research issues that we've only begun to address. For starters is
the question of how one manages multi-point connections that can
potentially contain any number of endpoints. We need efficient
distributed algorithms that can establish and manage such connections
using only local information. Routing is another interesting problem.
In point-to-point networks, this can be treated as least-cost path
problem. In a mulit-point network, we need to find the least-cost
tree connecting a given set of endpoints. This is known in combinatorial
optimization circles as the Steiner tree problem and is NP-complete.
Congestion control is another issue that takes on added dimensions in
multi-point networks.

Well, this is already too long, so I'll stop. Reactions anyone? Do you
think the notion of general purpose networks one that's worth pursuing?
Does anyone out there have other ideas on how to build such a beast?

-- 

Jon Turner 	Washington University in St. Louis 314-889-6193
UUCP:		jst@wucs.UUCP  or  ..!{ihnp4,seismo}!wucs!jst
ARPANET:	wucs!jst@seismo.ARPA
CSNET:		wucs!jst@seismo.ARPA%csnet-relay