📄 rfc1152.txt
字号:
causal consistency, in which systems ensure that operations happen in
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 the
increase in speed of network attachment to hosts of increasing
performance. These issues included:
- Media Access - There are aspects of media access that are
best handled by dedicated silicon, but there are also aspects
that are best left to a general-purpose processor.
- Compression - Some forms of compression/expansion may belong
on the network interface; most will be application-specific.
- Forward Error Correction - The predicted major packet loss
mode is packet drops due to internal network congestion, rather
than bit errors, so forward error correction internal to a
packet may not be useful. On the other hand, the latency cost
of not being able to recover from bit errors is very high.
Some proposals were discussed which suggest that FEC among
packet groups, with dedicated hardware support, is the way
to go.
- Encryption/Decryption - This is a computationally intensive
task. Most agree that if it is done with all traffic, some
form of hardware support is helpful. Where does it fit in the
protocol stack?
- Application Memory Mapping - How much of the host memory
structure should be exposed to the network interface?
Virtual memory and paging complicate this issue considerably.
- Communication with Other Channel Controllers - Opinions were
expressed that ranged from absolutely passive network
interfaces to interfaces that run major portions of the
operating system and bus arbitration codes.
- Blocking/Segmentation - The consensus is that B/S should
Partridge [Page 10]
RFC 1152 IRSG Workshop Report April 1990
occur wherever the transport layer is processed.
- Routing - This is related to communications with other
controllers. A routing-capable interface can reduce the bus
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 be
completely overshadowed by this issue if it is not solved well
and integrated into the overall host architecture. This points
out the need for some standardization of representation (IEEE
floating point, etc.)
Eric Cooper (CMU) summarized some initial experience with Nectar, a
high-speed fiber-optic LAN that has been built at Carnegie Mellon.
Nectar consists of an arbitrary mesh of crossbar switches connected
by means of 100 Mbps fiber-optic links. Hosts are connected to
crossbar switches via communication processor boards called CABs.
The CAB presents a memory-mapped interface to user processes and
off-loads all protocol processing from the host.
Preliminary performance figures show that latency is currently
limited by the number of VME operations required by the host-to-CAB
shared memory interface in the course of sending and receiving a
message. The bottleneck in throughput is the speed of the VME
interface: although processes running on the CABs can communicate
over Nectar at 70 Mbps, processes on the hosts are limited to
approximately 25 Mbps.
Jeff Mogul (DEC Western Research Lab) made these observations:
Although off-board protocol processors have been a popular means to
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-MIPS
CPU and a Gbps LAN, an off-board protocol processor will be of no
use. The bottleneck will not be the computation required to
implement the protocol, but the cost of moving the packet data into
the CPU's cache and the cost of notifying the user process that the
data is available. It will take far longer (hundreds of instruction
cycles) to perform just the first cache miss (required to get the
packet into the cache) than to perform all of the instructions
necessary to implement IP and TCP (perhaps a hundred instructions).
A high-speed network interface for a reasonably-priced system must be
designed with this cost structure in mind; it should also eliminate
as many CPU interrupts as possible, since interrupts are also very
expensive. It makes more sense to let a user process busy-wait on a
Partridge [Page 11]
RFC 1152 IRSG Workshop Report April 1990
network-interface flag register than to suspend it and then take an
interrupt; the normal CPU scheduling mechanism is more efficient than
interrupts if the network interactions are rapid.
David Greaves (Olivetti Research Ltd.) briefly described the need for
a total functionality interface architecture that would allow the
complete elimination of communication interrupts. He described the
Cambridge high-speed ring as an ATM cell-like interconnect that
currently runs at 500-1000 MBaud, and claims that ATM at that speed
is a done deal. Dave Tennenhouse also commented that ATM at high
speeds with parallel processors is not the difficult thing that
several others have been claiming.
Bob Beach (Ultra Technologies) started his talk with the observation
that networking could be really fast if only we could just get rid of
the hosts. He then supported his argument with illustrations of
80-MByte/second transfers to frame buffers from Crays that drop to
half that speed when the transfer is host-to-host. Using null
network layers and proprietary MAC layers, the Ultra Net system can
communicate application-to-application with ISO TP4 as the transport
layer at impressive rates of speed. The key to high-speed host
interconnects has been found to be both large packets and large (on
the order of one megabyte) channel transfer requests. Direct DMA
interfaces exhibit much smaller transfer latencies.
Derek McAuley (University Cambridge Computer Laboratory) described
work of the Fairisle project which is producing an ATM network based
on fast packet switches. A RISC processor (12 MIPS) is used in the
host interface to do segmentation/reassembly/demultiplexing. Line
rates of up to 150 Mbps are possible even with this modest processor.
Derek has promised that performance and requirement results from this
system will be published in the spring.
Bryan Lyles (XEROX PARC) volunteered to give an abbreviated talk in
exchange for discussion rights. He reported that Xerox PARC is
interested in ATM technology and wants to install an ATM LAN at the
earliest possible opportunity. Uses will include such applications
as video where guaranteed quality of service (QOS) is required. ATM
technology and the desire for guaranteed QOS places a number of new
constraints on the host interface. In particular, they believe that
they will be forced towards rate-based congestion control. Because
of implementation issues and burst control in the ATM switches, the
senders will be forced to do rate based control on a cell-by-cell
basis.
Don Tolmie (Los Alamos National Laboratory) described the High-
Performance Parallel Interface (HPPI) of ANSI task group X3T9.3. The
HPPI is a standardized basic building block for implementing, or
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 at
800 or 1600 Mbps over 25-meter twisted-pair copper cables in a
point-to-point configuration. The HPPI physical layer has almost
completed the standards process, and a companion HPPI data framing
standard is under way, and a Fiber Channel standard at comparable
speeds is also being developed. Major companies have completed, or
are working on, HPPI interfaces for supercomputers, high-end
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 similar
cost/performance) machines makes economic sense. Van Jacobson
contended that for workstations, a simple memory-mapped network
interface that provides packets visible to the host processor may
well be the ideal solution.
Bryan Lyles reiterated several of his earlier points, asserting that
when we talk about host interfaces and how to build them we should
remember that we are really talking about process-to-process
communication, not CPU-to-CPU communication. Not all processes run
on the central CPU, e.g., graphics processors and multimedia.
Outboard protocol processing may be a much better choice for these
architectures.
This is especially true when we consider that memory/bus bandwidth is
often a bottleneck. When our systems run out of bandwidth, we are
forced towards a NUMA model and multiple buses to localize memory
traffic.
Because of QOS issues, the receiver must be able to tell the sender
how fast it can send. Throwing away cells (packets) will not work
because unwanted packets will still clog the receiver's switch
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 talks
were rather general, discussing new approaches and old myths. The
other four talks discussed specific results on various aspects of
packet (or cell) dropping: how to avoid drops, how to mitigate their
impact on certain applications, a calculation of the end-to-end
throughput in the presence of drops, and how rate-based flow control
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 congestion
Partridge [Page 13]
RFC 1152 IRSG Workshop Report April 1990
control. Using economics, one can articulate questions about the
goals of congestion control, the minimal feedback necessary to
achieve those goals, and the incentive structure of congestion
control. Raj Jain (DEC) then discussed eight myths related to
congestion control in high-speed networks. Among other points, Raj
argued that (1) congestion problems will not become less important
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 (BBN
Communications Corporation) presented a back-of-the-envelope
calculation on the effect of cell drops on end-to-end throughput.
While at extremely low drop rates the retransmission strategies of
go-back-n and selective retransmission produced similar end-to-end
throughput, at higher drop rates selective retransmission achieved
much higher throughput. Next, Tony DeSimone (AT&T) told us why
high-speed networks are not just fast low-speed networks. If the
buffer/window ratio is fixed, the drop rate decreases as the network
speed increases. Also, data was presented which showed that adaptive
rate control can greatly decrease buffer utilization. Jamal
Golestani (Bellcore) then presented his work on stop-and-go queueing.
This is a simple stalling algorithm implemented at the switches which
guarantees no dropped packets and greatly reduces delay jitter. The
algorithm requires prior bandwidth reservation and some flow control
on sources, and is compatible with basic FIFO queues. In the last
talk, Victor Frost (University of Kansas) discussed the impact of
different dropping policies on the perceived quality of a voice
connection. When the source marks the drop priority of cells and the
switch drops low priority cells first, the perceived quality of the
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 now
under way at the University of Delaware to study architectures and
protocols for a high-speed network and packet switch capable of
operation to the gigabit regime over distances spanning the country.
It is intended for applications involving very large, very fast, very
bursty traffic typical of supercomputing, remote sensing, and
visualizing applications. The network is assumed to be composed of
fiber trunks, while the switch architecture is based on a VLSI
baseband crossbar design which can be configured for speeds from 25
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -