next up previous

User 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.  
 \ \epsfbox{figures/lfn.eps} \\  ...
 ...arbox{6in}{\renewcommand \normalsize{\footnotesize}

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:
\hbox{TCP window size} = \hbox{bandwidth} * \hbox{delay time}\end{displaymath} (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 up previous
Patrick Shopbell