Next: NETWORK PERFORMANCE
Up: NETWORK ARCHITECTURE
Previous: Network Protocol Layer
ATM is not a ``reliable'' protocol in the networking sense - bit
errors and congestion may cause cells to be dropped or lost in
transit; no attempt is made to verify delivery. In order to
facilitate reliable data transfer for scientific applications, as well
as to allow the use of the wealth of software tools already available,
we are running the standard IP protocols over ATM. We are using a
pseudo-standard implementation known as ``Classical IP'', which
defines a relationship between standard IP ``dot'' addressing and ATM
PVCs, as well as data packet segmentation and re-assembly algorithms
for converting between IP packets and ATM cells [1]
(i.e., AAL-5). Since the ATM switches know nothing of upper-level
protocols, the choice of IP as a user protocol affects merely the two
end-point systems. Those workstations both employ
FORE SBA-200 ATM interface
cards
to perform IP
packet segmentation and re-assembly in hardware. These interface
cards run at speeds up to OC-3 (155 Mbit/sec).
Figure 6:
In order to increase the TCP
acknowledgment window to values greater than 64 Kbytes, extended
TCP windows (i.e., RFC 1323) must be supported at the operating
system level. This support is virtually required for satellite
networking, especially in high-bandwidth applications. For the
Keck/ACTS network, the optimal extended TCP/IP window size is
approximately 3.5 Mbytes.
 |
Over the Classical IP level, we run the standard TCP/IP and UDP/IP
protocol suites. This enables the use of all the standard
network-based applications that are in widespread use on the Internet.
Common tools such as ftp, telnet, and the
X Window System
are part of
every observing run, as are additional special-purpose applications,
such as an audio conferencing tool (rat) and a shared whiteboard
tool (wb).
The most important impact of a satellite component on a high-speed
network is the relatively large delay introduced by the round-trip
signal travel time to the satellite. In our network, this travel time
is approximately 0.55 seconds, which corresponds to over 3 Mbytes of
data at DS-3 speeds (45 Mbit/sec). The problem has to do with the
connection-oriented nature of TCP/IP: TCP sends a very specific amount
of data, known as a ``window'', after which time it expects an
acknowledgment from the other end of the connection. This is the
manner in which TCP/IP is able to implement a ``reliable'' connection.
However, this window size is often very small; the default value for
workstations running the SunOS 4.1.4 operating system is 4 Kbytes. If
one were to use this system on our satellite network in its default
configuration, a window of data would be sent in 0.0007 seconds, after
which the sending system would be forced to wait 0.549 seconds for an
acknowledgment. In other words, the system would be running at 0.1%
efficiency, and the net throughput would reflect this: initial tests
of our system under such conditions showed bandwidths of
0.1-0.2 Mbit/sec.
Fortunately, this problem is well-known in the high-speed networking
community. Networks such as ours are known as ``long fat networks''
(LFN). The figure of merit for such networks is the window size, or
the bandwidth-delay product:
|  |
(1) |
(See Figure 6.) There is an Internet
Request For Comment
(RFC)
document on this
subject, RFC 1323 [5], and the problem has been discussed
extensively. Many current operating systems support the RFC 1323
extensions, and provide options to increase the TCP window size to
values in excess of 10 Mbytes. In the case of the SunOS operating
system (to which we are constrained by legacy control software at
Keck), we obtained the TCP-LFN package from Sun Consulting, which also
purports to support the RFC 1323 extensions for long fat networks.
Next: NETWORK PERFORMANCE
Up: NETWORK ARCHITECTURE
Previous: Network Protocol Layer
Patrick Shopbell
3/17/1998