As per Relevance of the word workshop, we have this rfc below:
Network Working Group C.
Request for Comments: 1152 BBN Systems and
April 1990
Workshop
Internet Research Steering Group Workshop
Very-High-Speed
Status of this
This memo is a report on a workshop sponsored by the
Research Steering Group. This memo is for information only.
RFC does not specify an Internet standard. Distribution of this
is unlimited
The goal of the workshop was to gather together a small number
leading researchers on high-speed networks in an
conducive to lively thinking. The hope is that by having such
workshop the IRSG has helped to stimulate new or improved research
the area of high-speed networks
Attendance at the workshop was limited to fifty people, and
had to apply to get in. Applications were reviewed by a
committee, which accepted about half of them. A few key
were invited directly by the program committee, without application
The workshop was organized by Dave Clark and Craig Partridge
This workshop report is derived from session writeups by each of
session chairman, which were then reviewed by the
participants
Session 1: Protocol Implementation (David D. Clark, Chair
This session was concerned with what changes might be required
protocols in order to achieve very high-speed operation
The session was introduced by David Clark (MIT LCS), who claimed
existing protocols would be sufficient to go at a gigabit per second
if that were the only goal. In fact, proposals for high-
networks usually include other requirements as well, such as
long distances, supporting many users, supporting new services
as reserved bandwidth, and so on. Only by examining the
requirements can one understand and compare various proposals
protocols. A variety of techniques have been proposed to
protocols to operate at high speeds, ranging from
Partridge [Page 1]
RFC 1152 IRSG Workshop Report April 1990
implementation to complete relayering of function. Clark
that currently even the basic problem to be solved is not clear,
alone the proper approach to the solution
Mats Bjorkman (Uppsala University) described a project that
the use of an outboard protocol processor to support high-
operation. He asserted that his approach would permit
processing of steady-state sequences of packets. Van Jacobson (LBL
reported results that suggest that existing protocols can operate
high speeds without the need for outboard processors. He also
that resource reservation can be integrated into a
protocol such as IP without losing the essence of the
architecture. This is in contrast to a more commonly held
that full connection setup will be necessary in order to
resource reservation. Jacobson said that he has an experimental
gateway that supports resource reservation for specific
sequences today
Dave Borman (Cray Research) described high-speed execution of TCP
a Cray, where the overhead is most probably the system and I/
architecture rather than the protocol. He believes that
such as TCP would be suitable for high-speed operation if the
and sequence spaces were large enough. He reported that the
speed of a TCP transfer between the processors of a Cray Y-MP
over 500 Mbps. Jon Crowcroft (University College London)
the current network projects at UCL. He offered a speculation
congestion could be managed in very high-speed networks by
to the sender any packets for which transmission capacity was
available
Dave Feldmeier (Bellcore) reported on the Bellcore participation
the Aurora project, a joint experiment of Bellcore, IBM, MIT,
UPenn, which has the goal of installing and evaluating two sorts
switches at gigabit speeds between those four sites. Bellcore
interested in switch and protocol design, and Feldmeier and his
are designing and implementing a 1 Gbps transport protocol
network interface. The protocol processor will have special
for such things as forward error correction to deal with ATM
loss in VLSI; a new FEC code and chip design have been developed
run at 1 Gbps
Because of the large number of speakers, there was no
discussion after this session
Partridge [Page 2]
RFC 1152 IRSG Workshop Report April 1990
Session 2: High-Speed Applications (Keith Lantz, Chair
This session focused on applications and the requirements they
on the underlying networks. Keith Lantz (Olivetti
California) opened by introducing the concept of the portable
- a world where a user is able to take her work with her wherever
goes. In such an office a worker can access the same services
the same people regardless of whether she is in the same
with those services and people, at home, or at a distant site (
as a hotel) - or whether she is equipped with a highly portable
multi-media workstation, which she can literally carry with
wherever she goes. Thus, portable should be interpreted as
to portability of access to services rather than to portability
hardware. Although not coordinated in advance, each of
presentations in this session can be viewed as a perspective on
portable office
The bulk of Lantz's talk focused on desktop teleconferencing -
integration of traditional audio/video teleconferencing
with workstation-based network computing so as to
geographically distributed individuals to collaborate, in real time
using multiple media (in particular, text, graphics, facsimile
audio, and video) and all available computer-based tools, from
respective locales (i.e., office, home, or hotel). Such a
places severe requirements on the underlying network. Specifically
it requires support for several data streams with widely
bandwidths (from a few Kbps to 1 Gbps) but generally low delay,
with minimal jitter (i.e., isochronous), and all synchronized
each other (i.e., multi-channel or media synchronization).
appears that high-speed network researchers are paying
attention to the last point, in particular. For example, the bulk
the research on ATM has assumed that channels have
connection request and burst statistics; this is clearly not the
in the context of desktop teleconferencing
Lantz also stressed the need for adaptive protocols, to
situations where the capacity of the network is exceeded, or where
is necessary to interoperate with low-speed networks, or where
factors suggest that the quality of service should change (e.g.,
increasing or decreasing the resolution of a video image).
adaptive protocols suggests, first, that the interface to the
protocols must be hardware-independent and based only on quality
service. Second, a variety of code conversion services should
available, for example, to convert from one audio encoding scheme
another. Promising examples of adaptive protocols in the
domain include variable-rate constant-quality coding, layered
embedded coding, progressive transmission, and (most recently,
UC-Berkeley) the extension of the concepts of structured graphics
Partridge [Page 3]
RFC 1152 IRSG Workshop Report April 1990
video, such that the component elements of the video image are
logically separate throughout the production-to-presentation cycle
Charlie Catlett (National Center for Supercomputing Applications
continued by analyzing a specific scientific application,
of a thunderstorm, with respect to its network requirements.
application was analyzed from the standpoint of identifying data
and the interrelationships between the computational algorithms,
supercomputer CPU throughput, the nature and size of the data set
and the available network services (throughput, delay, etc).
Simulation and the visualization of results typically
several steps
1.
2. Tessellation (transform simulation data into three-
geometric volume descriptions, or polygons
3. Rendering (transform polygons into raster image
For the thunderstorm simulation, the simulation and tessellation
currently done using a Cray supercomputer and the resulting
are sent to a Silicon Graphics workstation to be rendered
displayed. The simulation creates data at a rate of between 32
128 Mbps (depending on the number of Cray-2 processors working on
simulation) and the tessellation output data rate is in typically
the range of 10 to 100 Mbps, varying with the complexity of
visualization techniques. The SGI workstation can display 100,000
polygons/sec which for this example translates to up to 10
frames/sec. Analysis tools such as tracer particles and two
dimensional slices are used interactively at the workstation
pre-calculated polygon sets
In the next two to three years, supercomputer speeds of 10-30
and workstation speeds of up to 1 GFLOPS and 1
polygons/second display are projected to be available.
supercomputer power will yield a simulation data creation rate of
to several Gbps for this application. The increased
power will allow both tessellation and rendering to be done at
workstation. The use of shared window systems will allow
researchers on the network to collaborate on a simulation, with
possibility of each scientist using his or her own
techniques with the tessellation process running on his or
workstation. Further developments, such as network virtual memory
will allow the tessellation processes on the workstations to
variables directly in supercomputer memory
Partridge [Page 4]
RFC 1152 IRSG Workshop Report April 1990
Terry Crowley (BBN Systems and Technologies) continued the theme
collaboration, in the context of real-time video and audio,
multimedia workspaces, multimedia and video mail, distributed
systems, scientific visualization, network access to video and
information, transaction processing systems, and transferring
and computational results between workstations and supercomputers
In general, such applications could help groups collaborate
directly providing communication channels (real-time video,
multimedia workspaces), by improving and expanding on the kinds
information that can be shared (multimedia and video mail
supercomputer data and results), and by reducing replication and
complexity of sharing (distributed file systems, network access
video and image information).
Actual usage patterns for these applications are hard to predict
advance. For example, real-time video might be used for
conferencing, for video phone calls, for walking down the hall,
for providing a long-term shared viewport between remote locations
order to help establish community ties. Two characteristics
network traffic that we can expect are the need to provide
data streams to the end user and the need to synchronize
streams. These data streams will include real-time video, access
stored video, shared multimedia workspaces, and access to
multimedia data. A presentation involving multiple data streams
be synchronized in order to maintain cross-references between
(e.g., pointing actions within the shared multimedia workspace
are combined with a voice request to delete this and save that).
While much traffic will be point-to-point, a significant amount
traffic will involve conferences between multiple sites. A
providing a multicast capability is critical
Finally, Greg Watson (HP) presented an overview of ongoing work
the Hewlett-Packard Bristol lab. Their belief is that,
applications for high-speed networks employing supercomputers are
the technology drivers, the economic drivers will be
requiring moderate bandwidth (say 10 Mbps) that are used by
on the network
They are investigating how multimedia workstations can
distributed research teams - small teams of people who
geographically dispersed and who need to work closely on some area
research. Each workstation provides multiple video channels
together with some distributed applications running on
computers. The bandwidth requirements per workstation are about 40
Mbps, assuming a certain degree of compression of the video channels
Currently the video is distributed as an analog signal over
equipment. Ideally it would all be carried over a single,
wide-area network operating in the one-to-several Gbps range
Partridge [Page 5]
RFC 1152 IRSG Workshop Report April 1990
They have constructed a gigabit network prototype and are
experimenting with uncompressed video carried over the same
as normal data traffic
Session 3: Lightwave Technology and its Implications (Ira Richer, Chair
Bob Kennedy (MIT) opened the session with a talk on network design
an era of excess bandwidth. Kennedy's research is focused on multi
purpose networks in which bandwidth is not a scarce commodity
networks with bandwidths of tens of terahertz. Kennedy points
that a key challenge in such networks is that electronics cannot
up with fiber speeds. He proposes that we consider all-
networks (in which all signals are optical) with optoelectronic
or gateways capable of recognizing and capturing only
destined for them, using time, frequency, or code divisions of
huge bandwidth. The routing algorithms in such networks would
extremely simple to avoid having to convert fiber-optics into
electronic pathways to do switching
Rich Gitlin (AT&T Bell Labs) gave a talk on issues and
in broadband telecommunications networks, with emphasis on the
of fiber optic and photonic technology. A three-level
for a broadband telecommunications network was presented.
network is B-ISDN/ATM 150 (Mbps) based and consists of:
premises equipment (PBXs, LANs, multimedia terminals) that access
network via a router/gateway, a Network Node (which is a
performance ATM packet switch) that serves both as a LAN-to-
interconnect and as a packet concentrator for traffic destined
CPE attached to other Network Nodes, and a backbone layer
interconnects the NODES via a Digital Cross-Connect System
provide reconfigurable SONET circuits between the NODES (the use
circuits minizes delay and avoids the need for implementation
peak-transmission-rate packet switching). Within this framework,
most likely places for near-term application of photonics, apart
pure transport (ie, 150 Mbps channels in a 2.4 Gbps SONET system),
are in the Cross-Connect (a Wavelength Division Multiplexed
structure was described) and in next-generation LANs that
Gigabit per second throughputs by use of multiple fibers,
transmission, and new access mechanisms (such as store and forward).
A planned interlocation Bell Labs multimedia gigabit/sec
network, LuckyNet, was described that attempts to extend many of
above concepts to achieve its principal goals: provision of a
per second capability to a heterogeneous user community,
stimulation of applications that require Gpbs throughput (
applications are video conferencing and LAN interconnect), and,
the extent possible, be based on standards so that
with other Gigabit testbeds is possible
Partridge [Page 6]
RFC 1152 IRSG Workshop Report April 1990
Session 4: High Speed Networks and the Phone
(David Tennenhouse, Chair
David Tennenhouse (MIT) reported on the ATM workshop he hosted
two days previous to this workshop. His report will appear as
of the proceedings of his workshop
Wally St. John (LANL) followed with a presentation on the Los
gigabit testbed. This testbed is based on the High
Parallel Interface (HPPI) and on crossbar switch technology.
has designed its own 16x16 crossbar switch and has also evaluated
Network Systems 8x8 crossbar switch. Future plans for the
include expansion to the CASA gigabit testbed. The remote sites (
Diego Supercomputer Center, Caltech, and JPL) are
similarly to the LANL testbed. The long-haul interface is from
to/from SONET (using ATM if in time).
Wally also discussed some of the problems related to building
HPPI-SONET gateway
a) Flow control. The HPPI, by itself, is only readily
to 64 km because of the READY-type flow control used in
physical layer. The gateway will need to incorporate
buffers and independent flow control
b) Error-rate expectations. SONET is only specified to have
1E-10 BER on a per hop basis. This is inadequate for
links. Those in the know say that SONET will be much
but the designer is faced with the poor BER in the SONET spec
c) Frame mapping. There are several interesting issues to
considered in finding a good mapping from the HPPI
to the SONET frame. Some are what SONET STS levels will
available in what time frame, the availability of
service, and the error rate issue
Dan Helman (UCSC) talked about work he has been doing with
Long to examine the interconnection of Internet networks via an
B-ISDN network. Since network interfaces and packet processing
the expensive parts of high-speed networks, they believe it doesn'
make sense to use the ATM backbone only for transmission; it
be used for switching as well. Therefore gateways (either shared
a subnet or integrated with fast hosts) are needed to encapsulate
convert conventional protocols to ATM format. Gateways will
responsible for caching connections to recently
destinations. Since many short-lived low-bandwidth connections
foreseen (e.g., for mail and ftp), routing in the ATM network (to
up connections) should not be complicated - a form of static
Partridge [Page 7]
RFC 1152 IRSG Workshop Report April 1990
should be adequate. Connection performance can be monitored by
gateways. Connections are reestablished if unacceptable.
decision making can be done by gateways and route servers at
packet rates, rather than the high aggregate rate of the ATM network
One complicated issue to be addressed is how to
introduce an ATM backbone alongside the existing Internet
Session 5: Distributed Systems (David Farber, Chair
Craig Partridge (BBN Systems and Technologies) started this
by arguing that classic RPC does not scale well to gigabit-
networks. The gist of his argument was that machines are
faster and faster, while the round-trip delay of networks is
relatively constant because we cannot send faster than the speed
light. As a result, the effective cost of doing a simple RPC
measured in instruction cycles spent waiting at the sending machine
will become extremely high (millions of instruction cycles
waiting for the reply to an RPC). Furthermore, the methods
used to improve RPC performance, such as futures and parallel RPC,
not adequately solve this problem. Future requests will have to
made much much earlier if they are to complete by the time they
needed. Parallel RPC allows multiple threads, but doesn't solve
fact that each individual sequence of RPCs still takes a very
time
Craig went on to suggest that there are at least two possible
out of the problem. One approach is to try to do a lot of
(to waste bandwidth to keep the CPU fed). A limitation of
approach is that at some point the cache becomes so big that you
to keep in consistent with other systems' caches, and you
find yourself doing synchronization RPCs to avoid doing normal
(oops!). A more promising approach is to try to consolidate
being sent to the same machine into larger operations which can
sent as a single transaction, run on the remote machine, and
result returned. (Craig noted that he is pursuing this approach
his doctoral dissertation at Harvard).
Ken Schroder (BBN Systems and Technologies) gave a talk on
challenges of combining gigabit networks with wide-area
distributed operating systems. Ken feels the key goals of wide
distributed systems will be to support large volume data
between users of conferencing and similar applications, and
deliver information to a large number of end users sharing
such as satellite image databases. These distributed systems will
motivated by the natural distribution of users, of information and
expensive special purpose computer resources
Ken pointed to three of the key problems that must be addressed
Partridge [Page 8]
RFC 1152 IRSG Workshop Report April 1990
the system level in these environments: how to provide
utilization; how to manage consistency and synchronization in
presence of concurrency and non-determinism; and how to
scalable system and application services. Utilization is key only
high performance applications, where current systems would be
by the cost of factors such as repeatedly copying messages
converting data representations and switching between application
operating system. Concurrency can be used improve performance,
is also likely to occur in many programs inadvertently because
distribution. Techniques are required both to exploit
when it is needed, and to limit it when non-determinism can lead
incorrect results. Extensive research on ensuring consistency
resolving resource conflicts has been done in the database area
however distributed scheduling and the need for high
despite partial system failures introduce special problems
require additional research. Service scalability will be required
support customer needs as the size of the user community grow.
will require attention both ensuring that components do not
when they are subdivided across additional processors to support
larger user population, and to ensure that performance does to
user can be affordably maintained as new users are added
In a bold presentation, Dave Cheriton (Stanford) made a
argument that we are making a false dichotomy between
operating systems and networks. In a gigabit world, he argued,
major resource in the system is the network, and in a
operating system we would expect such a critical resource to
managed by the operating system. Or, put another way, the
network distributed operating system should manage the network
Cheriton went on to say that if a gigabit distributed
system is managing the network, then it is perfectly reasonable
make the network very dumb (but fast) and put the system
in the operating systems on the hosts that form the
system
In another talk on interprocess communication, Jonathan Smith (UPenn
again raised the problem of network delay limiting RPC performance
In contrast to Partridge's earlier talk, Smith argued that
appropriate approach is anticipation or caching. He justified
argument with a simple cost example. If a system is doing a
fetch between two systems which have a five millisecond round-
network delay between them, the cost of fetching n pages is
5 msec + (n-1) * 32
Thus the cost of fetching an additional page is only 32 usec,
underfetching and having to make another request to get a page
missed costs 5000 usec. Based on these arguments, Smith
Partridge [Page 9]
RFC 1152 IRSG Workshop Report April 1990
that we re-examine work in virtual memory to see if there
comfortable ways to support distributed virtual memory
anticipation
In the third talk on RPC in the session, Tommy Joseph (Olivetti),
reasons similar to those of Partridge and Smith, argued that we
to get rid of RPC and give programmers alternative
paradigms. He sketched out ideas for asynchronous paradigms
causal consistency, in which systems ensure that operations happen
the proper order, without synchronizing through a single system
Session 6: Hosts and Host Interfaces (Gary Delp, Chair
Gary Delp (IBM Research) discussed several issues involved in
increase in speed of network attachment to hosts of
performance. These issues included
- Media Access - There are aspects of media access that
best handled by dedicated silicon, but there are also
that are best left to a general-purpose processor
- Compression - Some forms of compression/expansion may
on the network interface; most will be application-specific
- Forward Error Correction - The predicted major packet
mode is packet drops due to internal network congestion,
than bit errors, so forward error correction internal to
packet may not be useful. On the other hand, the latency
of not being able to recover from bit errors is very high
Some proposals were discussed which suggest that FEC
packet groups, with dedicated hardware support, is the
to go
- Encryption/Decryption - This is a computationally
task. Most agree that if it is done with all traffic,
form of hardware support is helpful. Where does it fit in
protocol stack
- Application Memory Mapping - How much of the host
structure should be exposed to the network interface
Virtual memory and paging complicate this issue considerably
- Communication with Other Channel Controllers - Opinions
expressed that ranged from absolutely passive
interfaces to interfaces that run major portions of
operating system and bus arbitration codes
- Blocking/Segmentation - The consensus is that B/S
Partridge [Page 10]
RFC 1152 IRSG Workshop Report April 1990
occur wherever the transport layer is processed
- Routing - This is related to communications with
controllers. A routing-capable interface can reduce the
requirements by a factor of two
- Intelligent participation in the host structure as a gateway
router, or bridge
- Presentation Layer issues - All of the other overheads can
completely overshadowed by this issue if it is not solved
and integrated into the overall host architecture. This
out the need for some standardization of representation (
floating point, etc.)
Eric Cooper (CMU) summarized some initial experience with Nectar,
high-speed fiber-optic LAN that has been built at Carnegie Mellon
Nectar consists of an arbitrary mesh of crossbar switches
by means of 100 Mbps fiber-optic links. Hosts are connected
crossbar switches via communication processor boards called CABs
The CAB presents a memory-mapped interface to user processes
off-loads all protocol processing from the host
Preliminary performance figures show that latency is
limited by the number of VME operations required by the host-to-
shared memory interface in the course of sending and receiving
message. The bottleneck in throughput is the speed of the
interface: although processes running on the CABs can
over Nectar at 70 Mbps, processes on the hosts are limited
approximately 25 Mbps
Jeff Mogul (DEC Western Research Lab) made these observations
Although off-board protocol processors have been a popular means
connect a CPU to a network, they will be less useful in the future
In the hypothetical workstation of the late 1990s, with a 1000-
CPU and a Gbps LAN, an off-board protocol processor will be of
use. The bottleneck will not be the computation required
implement the protocol, but the cost of moving the packet data
the CPU's cache and the cost of notifying the user process that
data is available. It will take far longer (hundreds of
cycles) to perform just the first cache miss (required to get
packet into the cache) than to perform all of the
necessary to implement IP and TCP (perhaps a hundred instructions).
A high-speed network interface for a reasonably-priced system must
designed with this cost structure in mind; it should also
as many CPU interrupts as possible, since interrupts are also
expensive. It makes more sense to let a user process busy-wait on
Partridge [Page 11]
RFC 1152 IRSG Workshop Report April 1990
network-interface flag register than to suspend it and then take
interrupt; the normal CPU scheduling mechanism is more efficient
interrupts if the network interactions are rapid
David Greaves (Olivetti Research Ltd.) briefly described the need
a total functionality interface architecture that would allow
complete elimination of communication interrupts. He described
Cambridge high-speed ring as an ATM cell-like interconnect
currently runs at 500-1000 MBaud, and claims that ATM at that
is a done deal. Dave Tennenhouse also commented that ATM at
speeds with parallel processors is not the difficult thing
several others have been claiming
Bob Beach (Ultra Technologies) started his talk with the
that networking could be really fast if only we could just get rid
the hosts. He then supported his argument with illustrations
80-MByte/second transfers to frame buffers from Crays that drop
half that speed when the transfer is host-to-host. Using
network layers and proprietary MAC layers, the Ultra Net system
communicate application-to-application with ISO TP4 as the
layer at impressive rates of speed. The key to high-speed
interconnects has been found to be both large packets and large (
the order of one megabyte) channel transfer requests. Direct
interfaces exhibit much smaller transfer latencies
Derek McAuley (University Cambridge Computer Laboratory)
work of the Fairisle project which is producing an ATM network
on fast packet switches. A RISC processor (12 MIPS) is used in
host interface to do segmentation/reassembly/demultiplexing.
rates of up to 150 Mbps are possible even with this modest processor
Derek has promised that performance and requirement results from
system will be published in the spring
Bryan Lyles (XEROX PARC) volunteered to give an abbreviated talk
exchange for discussion rights. He reported that Xerox PARC
interested in ATM technology and wants to install an ATM LAN at
earliest possible opportunity. Uses will include such
as video where guaranteed quality of service (QOS) is required.
technology and the desire for guaranteed QOS places a number of
constraints on the host interface. In particular, they believe
they will be forced towards rate-based congestion control.
of implementation issues and burst control in the ATM switches,
senders will be forced to do rate based control on a cell-by-
basis
Don Tolmie (Los Alamos National Laboratory) described the High
Performance Parallel Interface (HPPI) of ANSI task group X3T9.3.
HPPI is a standardized basic building block for implementing,
Partridge [Page 12]
RFC 1152 IRSG Workshop Report April 1990
connecting to, networks at the Gbps speeds, be they ring, hub
cross-bar, or long-haul based. The HPPI physical layer operates
800 or 1600 Mbps over 25-meter twisted-pair copper cables in
point-to-point configuration. The HPPI physical layer has
completed the standards process, and a companion HPPI data
standard is under way, and a Fiber Channel standard at
speeds is also being developed. Major companies have completed,
are working on, HPPI interfaces for supercomputers, high-
workstations, fiber-optic extenders, and networking components
The discussion at the end of the session covered a range of topics
The appropriateness of outboard protocol processing was questioned
Several people agreed that outboarding on a Cray (or
cost/performance) machines makes economic sense. Van
contended that for workstations, a simple memory-mapped
interface that provides packets visible to the host processor
well be the ideal solution
Bryan Lyles reiterated several of his earlier points, asserting
when we talk about host interfaces and how to build them we
remember that we are really talking about process-to-
communication, not CPU-to-CPU communication. Not all processes
on the central CPU, e.g., graphics processors and multimedia
Outboard protocol processing may be a much better choice for
architectures
This is especially true when we consider that memory/bus bandwidth
often a bottleneck. When our systems run out of bandwidth, we
forced towards a NUMA model and multiple buses to localize
traffic
Because of QOS issues, the receiver must be able to tell the
how fast it can send. Throwing away cells (packets) will not
because unwanted packets will still clog the receiver's
interface, host interface, and requires processing to throw away
Session 7: Congestion Control (Scott Shenker, Chair
The congestion control session had six talks. The first two
were rather general, discussing new approaches and old myths.
other four talks discussed specific results on various aspects
packet (or cell) dropping: how to avoid drops, how to mitigate
impact on certain applications, a calculation of the end-to-
throughput in the presence of drops, and how rate-based flow
can reduce buffer usage. Thumbnail sketches of the talks follow
In the first of the general talks, Scott Shenker (XEROX PARC
discussed how ideas from economics can be applied to
Partridge [Page 13]
RFC 1152 IRSG Workshop Report April 1990
control. Using economics, one can articulate questions about
goals of congestion control, the minimal feedback necessary
achieve those goals, and the incentive structure of
control. Raj Jain (DEC) then discussed eight myths related
congestion control in high-speed networks. Among other points,
argued that (1) congestion problems will not become less
when memory, processors, and links become very fast and cheap, (2)
window flow control is required along with rate flow control, and (3)
source-based controls are required along with router-based control
In the first of the more specific talks, Isidro Castineyra (
Communications Corporation) presented a back-of-the-
calculation on the effect of cell drops on end-to-end throughput
While at extremely low drop rates the retransmission strategies
go-back-n and selective retransmission produced similar end-to-
throughput, at higher drop rates selective retransmission
much higher throughput. Next, Tony DeSimone (AT&T) told us
high-speed networks are not just fast low-speed networks. If
buffer/window ratio is fixed, the drop rate decreases as the
speed increases. Also, data was presented which showed that
rate control can greatly decrease buffer utilization.
Golestani (Bellcore) then presented his work on stop-and-go queueing
This is a simple stalling algorithm implemented at the switches
guarantees no dropped packets and greatly reduces delay jitter.
algorithm requires prior bandwidth reservation and some flow
on sources, and is compatible with basic FIFO queues. In the
talk, Victor Frost (University of Kansas) discussed the impact
different dropping policies on the perceived quality of a
connection. When the source marks the drop priority of cells and
switch drops low priority cells first, the perceived quality of
connection is much higher than when cells are dropped randomly
Session 8: Switch Architectures (Dave Sincoskie, Chair
Dave Mills (University of Delaware) presented work on a project
under way at the University of Delaware to study architectures
protocols for a high-speed network and packet switch capable
operation to the gigabit regime over distances spanning the country
It is intended for applications involving very large, very fast,
bursty traffic typical of supercomputing, remote sensing,
visualizing applications. The network is assumed to be composed
fiber trunks, while the switch architecture is based on a
baseband crossbar design which can be configured for speeds from 25
Mbps to 1 Gbps
Mills' approach involves an externally switched architecture in
the timing and routing of flows between crossbar switches
determined by sequencing tables and counters in high-speed
Partridge [Page 14]
RFC 1152 IRSG Workshop Report April 1990
local to each crossbar. The switch program is driven by
reservation-TDMA protocol and distributed scheduling
running in a co-located, general-purpose processor. The end-to-
customers are free to use any protocol or data format consistent
the timing of the network. His primary interest in the
phases of the project is the study of appropriate reservation
scheduling algorithms. He expect these algorithms to have much
common with the PODA algorithm used in the SATNET and
satellite systems and to the algorithms being considered for
Multiple Satellite System (MSS).
John Robinson (JR, BBN Systems and Technologies) gave a talk
Beyond the Butterfly, which described work on a design for an
cell switch, known as MONET. The talk described strategies
buffering at the input and output interfaces to a switch
(crossbar or butterfly). The main idea was that cells should
introduced to the switch fabric in random sequence and to
fabric entry ports to avoid persistent traffic patterns having
cell loss in the switch fabric, where losses arise due to
at output ports or within the switch fabric (in the case of
butterfly). Next, the relationship of this work to an earlier
for a large-scale parallel processor, the Monarch, was described.
closing, JR offered the claim that this class of switch is
in current technology (barely) for operation over SONET OC-48 2.4
Gbps links
Dave Sincoskie (Bellcore) reported on two topics: recent
construction at Bellcore, and high-speed processing of ATM
carrying VC or DG information. Recent switch design has resulted
a switch architecture named SUNSHINE, a Batcher-banyan switch
uses recirculation and multiple output banyans to resolve
and increase throughput. A paper on this switch will be published
ISS '90, and is available upon request from the author. One of
interesting traffic results from simulations of SUNSHINE shows
per-port output queues of up to 1,000 cells (packets) may
necessary for bursty traffic patterns. Also, Bill Marcus (
Bellcore) has recently produced Batcher-banyan (32x32) chips
test up to 170Mb/sec per port
The second point in this talk was that there is little difference
the switching processing of Virtual Circuit (VC) and Datagram (DG
traffic that which has been previously broken into ATM cells at
network edge. The switch needs to do a header translation
followed by some queueing (not necessarily FIFO). The
translation of the VC and DG cells differs mainly in the
organization of the address translation tables (dense vs. sparse).
The discussion after the presentations seemed to wander off the
Partridge [Page 15]
RFC 1152 IRSG Workshop Report April 1990
of switching, back to some of the source-routing vs. network
issues discussed earlier in the day
Session 9: Open Mike Night (Craig Partridge, Chair
As an experiment, the workshop held an open mike session during
evening of the second day. Participants were invited to speak for
to five minutes on any subject of their choice. Minutes of
session are sketchy because the chair found himself pre-occupied
keeping speakers roughly within their time limits
Charlie Catlett (NSCA) showed a film of the thunderstorm
he discussed earlier
Dave Cheriton (Stanford) made a controversial suggestion that
one could manage congestion in the network simply by using a
price curve, in which sending large amounts of data
exponentially more than sending small amounts of data (thus
people only to ask for large bandwidth when they needed it,
having them pay so much, that we can afford to give it to them).
Guru Parulkar (Washington University, St. Louis) argued that
recent discussion on appropriateness of existing protocol and
for new protocols (protocol architecture) for gigabit
lacks the right focus. The emphasis of the discussion should be
what is the right functionality for gigabit speeds, which is
per packet processing, combination of rate and window based
control, smart retransmission strategy, appropriate partitioning
work among host cpu+os, off board cpu, and custom hardware,
others. It is not surprising that the existing protocols can
modified to include this functionality. By the same token, it is
surprising that new protocols can be designed which take advantage
lessons of existing protocols and also include other
necessary for gigabit speeds
Raj Jain (DEC) suggested we look at new ways to measure
performance, suggesting our current metrics are
informative
Dan Helman (UCSC) asked the group to consider, more carefully,
exactly the users of the network will be. Large consumers? or
small consumers
Partridge [Page 16]
RFC 1152 IRSG Workshop Report April 1990
Session 10: Miscellaneous Topics (Bob Braden, Chair
As its title implies, this session covered a variety of
topics relating to high-speed networking
Jim Kurose (University of Massachussetts) described his studies
scheduling and discard policies for real-time (constrained delay
traffic. He showed that by enforcing local deadlines at
along the path, it is possible to significantly reduce overall
for such traffic. Since his results depend upon the traffic
assumptions, he ended with a plea for work on traffic models,
that Poisson models can sometimes lead to results that are wrong
many orders of magnitude
Nachum Shacham (SRI International) discussed the importance of
correction schemes that can recover lost cells, and as an
presented a simple scheme based upon longitudinal parity. He
showed a variant, diagonal parity, which allows a single missing
to be recreated and its position in the stream determined
Two talks concerned high-speed LANs. Biswanath Muhkerjee (UC Davis
surveyed the various proposals for fair scheduling on
bus networks, especially those that are distance insensitive, i.e.,
that can achieve 100% channel utilization independent of the
length and data rate. He described in particular his own scheme
which he calls p-i persistant
Howard Salwen (Proteon), speaking in place of Mehdi Massehi of
Zurich who was unable to attend, also discussed high-speed
technologies. At 100 Mbps, a token ring has a clear advantage,
at 1 Gbps, the speed of light kills 802.6, for example. He
described Massehi's reservation-based scheme, CRMA (Cyclic
Reservation Multiple-Access).
Finally, Yechiam Yemeni (YY, Columbia University) discussed his
on a protocol silicon compiler. In order to exploit the
parallelism, he is planning to use one processor per connection
The session closed with a spirited discussion of about the
merits of building an experimental network versus simulating it
Proponents of simulation pointed out the high cost of building
prototype and limitation on the solution space imposed by
particular hardware realization. Proponents of building
that artificial traffic can never explore the state space of
network as well as real traffic can, and that an
prototype is important for validating simulations
Partridge [Page 17]
RFC 1152 IRSG Workshop Report April 1990
Session 11: Protocol Architectures (Vint Cerf, Chair
Nick Maxemchuk (AT&T Bell Labs) summarized the distinctions
circuit switching, virtual circuits, and datagrams. Circuits
good for (nearly) constant rate sources. Circuit switching
resources for the entire period of service. You have to set up
resource allocation before using it. In a 1.7 Gbps network, a 3000-
mile diameter consumes 10**7 bytes during the circuit set-up round
trip time, and potentially the same for circuit teardown.
service requirements (file transfer, facsimile transmission) are
smaller than the wasted 2*10**7 bytes these circuit management
impose. (Of course, these costs are not as dramatic if the
bandwidth is less than the maximum possible.)
Virtual circuits allow shared use of bandwidth (multiplexing)
the primary source of traffic is idle (as in Voice Time
Speech Interpolation). The user notifies the network of
usage
Datagrams (DG) are appropriate when there is no prior knowledge
use statistics or usage is far less than the capacity wasted
circuit or virtual circuit set-up. One can adaptively route
among equivalent resources
In gigabit ATMs, the high service speed and decreased cell
increases the relative burstiness of service requests. All of
characteristics combine to make DG service very attractive
Maxemchuk then described a deflection routing notion in which
would be broken into units of fixed length and allowed into
network when capacity was available and routed out by any
channel, with preference being given to the channel on the
path. This idea is similar to the hot potato routing of Paul Baran'
1964 packet switching design. With buffering (one buffer),
achieved a theoretical 90% utilization. Large reassembly
provide for better throughput
Maxemchuk did not have an answer to the question: how do you
sure empty "slots" are available where needed? This is rather
the problem encountered by D. Davies at the UK National
Laboratory in his isarythmic network design in which a finite
of crates are available for data transport throughout the network
Guru Parulkar (Washington University, St. Louis) presented a
view of an Internet architecture in which some portion of the
would operate at gigabit speeds. In his model, internet, transport
and application protocols would operate end to end. The
functions would be reflected in gateways and in the host/
Partridge [Page 18]
RFC 1152 IRSG Workshop Report April 1990
interface, as they are in the current Internet. However,
internet would support a new type of service called a congram
aims at combining strengths of both soft connection and datagram
In this architecture, a variable grade of service would be provided
Users could request congrams (UCON) or the system could set them
internally (Picons) to avoid end-to-end setup latency. The
grades of service could be requested, conceptually, by
various required (desired) levels of error control, throughput
delay, interarrival jitter, and so on. Gateways based on
switches, for example, would use packet processors at entry/exit
do internet specific per packet processing, which may
fragmentation and reassembly of packets (into and out of ATM cells).
At the transport level, Parulkar argued for protocols which
provide application-oriented flow and error control with simple
packet processing. He also mentioned the notion of a generalized
(GRPC) in which code, data, and execution might be variously local
remote from the procedure initiator. GRPC can be implemented
network level virtual storage mechanisms
The basic premise of Raj Yavatkar's presentation (University
Kentucky) was that processes requiring communication service
specify their needs in terms of peak and average data rate as well
defining burst parameters (frequency and size). Bandwidth for
given flow would be allocated at the effective data rate that
computed on the basis of flow parameters. The effective data
lies somewhere between the peak and average data rate based on
burst parameters. Statistical multiplexing would take up the
between peak and effective rate when a sudden burst of
arrives. Bounds on packet loss rate can be computed for a given
of flow parameters and corresponding effective data rate
This presentation led to a discussion about deliberate
of inter-process communication demands to match the requested
(service) profile. This point was made in response to
observation that we often have little information about
behavior and might have trouble estimating the network
requirements of any particular program
Architectural
An attempt was made to conduct a high-level discussion on
architectural questions. The discussion yielded a variety
opinions
1. The Internet would continue to exist in a form
to its current incarnation, and gateways would be required
Partridge [Page 19]
RFC 1152 IRSG Workshop Report April 1990
at least to interface the existing facilities to the
speed packet switching environment
2. Strong interest was expressed by some participants in
to raw (naked ATM) services. This would permit
to construct their own gigabit nets, at the IP level, at
rate. The extreme view of this was taken by David
who would prefer to have control over routing decisions
other behavior of the ATM network
3. The speed of light problem (latency, round-trip delay
is not going to go away and will have serious impact
control of the system. The optimistic view was taken
for example, by Craig Partridge and Van Jacobson, who
that many of the existing network and
management mechanisms used in the present Internet
would suffice, if suitably implemented, at higher speeds
A less rosy view was taken by David Clark who
(as did others) that many transactions would be serviced
much less than one round-trip time, so that any end-to-
controls would be largely useless
4. For applications requiring fixed, periodic service
reservation of resource seemed reasonably attractive to
participants, as long as the service period dominated
set-up time (round-trip delay) by an
margin
5. There was much discussion throughout the workshop
congestion control and flow control. Although
problems were not new, they took on somewhat
character in the presence of much higher round-trip
(measured in bits outstanding). One view is that end-to-
flow control is needed, in any case, to moderate
sending to limited bandwidth receivers. End-to-end
control may not, however, be sufficient to protect
interior of the network from congestion problems,
additional, intra-network means are needed to cope
congestion hot spots. Eventually such
have to be reflected to the periphery of the network
moderate traffic sources
6. There was disagreement on the build or
question. One view was in favor of building
components so as to collect and understand live
data. Another view held that without some
simulation, one might have little idea what to
(for example, Sincoskie's large buffer pool requirement
Partridge [Page 20]
RFC 1152 IRSG Workshop Report April 1990
not apparent until the system was simulated).
Comments from Workshop Evaluation
At the end of the IRSG workshop, we asked attendees to fill out
evaluation form. Of the fifty-one attendees, twenty-nine (56%)
turned in a form
The evaluation form asked attendees to answer two questions
#1. Do you feel that having attended this workshop will help
in your work on high speed networks during the next year
#2. What new ideas, questions, or issues, did you feel
brought up in the workshop
In this section we discuss the answers we got to both questions
Question #1
There was a satisfying unanimity of opinion on question #1. Twenty
four attendees answered yes, often strongly (e.g., Absolutely
very much so). Of the remaining five respondents, three said
expected it to have some effect on their research and only two
the workshop would have little or no effect
Some forms had some additional notes about why the workshop
them. Several people mentioned that there was considerable
to simply meeting and talking with people they hadn't met before.
few other people noted that the workshop had broadened
perspective, or improved their understanding of certain issues.
couple of people noted that they'd heard ideas they thought
could use immediately in their research
Question #2
Almost everyone listed ideas they'd seen presented at the
which were new to them
It is clear that which new ideas were important was a matter
perspective - the workshop membership was chosen to represent a
spectrum of specialties, and people in different specialities
intrigued by different ideas. However, there were some
themes raised in many questionnaires
(1) Limitations of our traffic models. This particular
was mentioned, in some form, on many forms. The
Partridge [Page 21]
RFC 1152 IRSG Workshop Report April 1990
generally felt we didn't understand how network traffic
behave on a gigabit network, and were concerned that
might design (or worse, standardize) network protocols
high speed networks that would prove inadequate when
with real traffic. Questions were raised about closed-
vs. open-loop traffic models and the effects of varying
of service. This concern led several people to encourage
construction of a high-speed testbed, so we can actually
some real traffic
(2) Congestion control. Despite the limitations of our
models, respondents felt that congestion control at
switching elements and network wide was going to be even
important than today, due to the wider mix of traffic
will appear on gigabit networks. Most forms mentioned
least one of the congestion control talks as a containing
new idea. The talks by Victor Frost, Jamal Golestani
Scott Shenker received the most praise. Some attendees
also interested in methods for keeping the lower-
switching fabric from getting congested and mentioned
talks by Robinson and Maxemchuk as of interest
(3) Effects of fixed delay. While the reviews were by no
unanimous, many people had come to the conclusion that
most serious problem in gigabit networking was not bandwidth
but delay. The workshop looked at this issue in
guises, and most people listed at least one aspect of
delay as a challenging new problem. Questions that
mentioned include
- How to avoid a one round-trip set up delay, for less than
round-trip time's worth of data
- How to recover from error without retransmission (and
additional network delays)? Several people were intrigued
Nachum Shacham's work on error detection and recovery
- Should we use window flow-control or rate-based flow
when delays were long
- Can we modify the idea of remote procedure calls to deal
the fact that delays are relatively long
A couple of attendees noted that while some of these problems
similar to those of today, the subtle differences caused by operating
network at gigabit speeds led them to believe the actual approaches
solving these problems would have to be very different from those
Partridge [Page 22]
RFC 1152 IRSG Workshop Report April 1990
today
Security
Security issues are not discussed in this memo
Author's
Craig
Bolt Beranek and Newman Inc
50 Moulton
Cambridge, MA 02138
Phone: (617) 873-2459
EMail: craig@BBN.
Partridge [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
