Fortunately, this problem is well-known in the high-speed networking community. Networks such as ours are known as ``long fat networks'' (LFN; see RFC 1323 ). 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 purports to support the RFC 1323 extensions. Unfortunately, a number of limitations of SunOS 4.1.4 conspire to prohibit one from obtaining extremely large window sizes, regardless of the TCP-LFN software. In our case, the compiled-in kernel limit of 2 Mbytes of Mbuf memory (i.e., IP packet wrappers) turned out to be the major constraint, limiting our window size to no more than 1 Mbyte. Indeed, our final tuned network delivered the expected maximum TCP/IP performance of approximately 15 Mbit/sec ( of OC-1). Although perhaps disappointing in a relative sense, this bandwidth is far in excess of T1 Ethernet speed (1.44 Mbit/sec) and allows an 8 Mbyte image to be transferred in approximately 5 seconds. As a further comparison, this bandwidth exceeds by 50% that which is available on the local area Ethernet network at the Keck Telescope itself. Figure 2 illustrates typical bandwidth measurements of our network for UDP and TCP, the latter before and after the network was upgraded to fiber in Hawaii. While network performance was perhaps not at the level desired, due to developing infrastructure in Hawaii and idiosyncrasies within the operating system, issues of network reliability had far greater impact on our remote observing operation. The experimental and limited nature of the ACTS program created a number of difficulties which one would almost certainly not face if using a more developed and/or commercial satellite system. The impact of the reliability issue is that at least one observer must be sent to Hawaii to use the telescope, in case of ACTS-related problems.