Transmission of Medical Images over Wide Area Networks

Lister Hill National Center for Biomedical Communications

Abstract: Rapid transmission of medical image data across wide area networks remains a technical challenge, due to the high data volume of the images and the transmission rates typically achievable. We are investigating two methods for potentially achieving better transmission rates when using the TCP protocol: (1) multisocket transmission, an application-level alternative to conventional single- channel TCP transmission; and (2) implementations of Internet RFC 1323, which specifies TCP extensions for high performance. This paper discusses transmission rate limitations in current TCP and presents results to date in using these alternative methods to send large image files across the Internet and across dedicated high-speed links with long signal path delays.

Keywords: medical images, wide area networks, transmission rate, TCP/IP, multisocket, RFC 1323, bandwidth, delay

1.0 Introduction

Wide area network delivery of large amounts of data is a topic of increasing interest, particularly for the transmission of biomedical images, such as the Visible Human digital color slices, because of the large sizes of the image files and the need to disseminate them on a national or international scale. Network protocols have a direct impact on the transmission rate achievable. At NLM's Communications Engineering Branch (CEB), we are focusing on the transport protocol and its relationship to link performance. We are investigating performance on the critical communications links of today (Internet links) and also on emerging high-speed optical fiber and satellite links. While much attention has been given to the emplacement of links with high physical capacity in building the National Information Infrastructure, the role of the transport protocol is also critical, since this protocol incorporates data flow control. The most widely-used transport protocol for Internet communication is TCP.

2.0 TCP characteristics affecting transmission rate performance

TCP windows and data flow. To control data flow, TCP uses windows on the sequence number spaces corresponding to the byte streams being sent and received. The TCP send window is illustrated in Figure 1. The send window slides to the right in the stream of bytes to be transmitted (send sequence space) as acknowledgments are received for sequence numbers within the window, allowing new packets to be sent to the network. Note that TCP sends data in units of packets, but acknowledges data by using the sequence numbers of bytes in the data stream being sent. For example, in Figure 1, the receipt of the packet containing bytes 512-1023 would be acknowledged by transmitting a "1024" (next expected byte) back to the sender. On the receive end, the receive window incorporates a similar sliding window scheme. The receive window size is a measure of the amount of buffer area that the receiver has currently available to receive data. At this end of the communication, there is a conceptual byte stream corresponding to all of the bytes to be received. The receive window slides to the right in this conceptual stream (receive window space) as data is received into and emptied from its available buffer area.

The TCP receiver transmits its current window size to the sender in the TCP header. The sender uses this receive window size as one of its key parameters in controlling data flow.

The sending TCP maintains a limit called the congestion window which, absent any packet loss, is the same size as the receive window. TCP maintains a dynamically-computed estimate of the round-trip time (RTT) for data transfer; when the RTT decreases, it assumes less congestion on the network, and will increase the congestion window size; similarly, when the RTT increases, TCP decreases the congestion window size.

At any time, the send window behaves as if its size S is given by [1]:

S = minimum(receive window, congestion window).

The larger the send window, the more data can be sent to the network, hence the greater throughput potential.

We are analyzing TCP performance in two network environments:

Case 1: Bandwidth-delay limited environment. If the network environment is contention-free (such as a dedicated point-to-point satellite link), the congestion window will be sized the same as the receive window. Hence, the limiting factor for S becomes only the receive window size. In order to maintain full use of a TCP connection at a specified bandwidth, the following relationship must hold:

receive window >= bandwidth * delay

where delay is the round-trip time mentioned above. If a network's throughput is determined by the above relationship, we refer to the network as bandwidth-delay limited. For example, in order to achieve a throughput of 50,000 bytes/second over a link with a 200 millisecond delay, the receive window must be at least 10,000 bytes in size. In current TCP, the receive window size is limited to 2**16-1. This limitation, commonly called the "64K window limit", results from the fact that the receive window size is passed to the sender in the TCP header, where the data field allocated to hold the window size is only two bytes in length. This has serious implications for network transmissions where the transmission distance, and hence the delay is great , and the desired throughput is high. These so-called "long, fat networks" (LFNs) are directly impacted by the receive window limitation in current TCP [2]. The achievable bandwidth in current TCP may be calculated by

bandwidth <= (2**16-1)/ delay.

For example a transmission with a network delay of 50 milliseconds will have a throughput limited by about 1.3 million bytes/second, regardless of the underlying physical capacity of the link. Institutions such as NLM desire to transmit many megabytes of data rapidly across long distances; these are precisely the class of users suited to LFNs, and also those for which the TCP window limitation becomes a potential problem. Figure 2 illustrates the bandwidth-delay limits under current TCP for a range of network delays, by graphing the relationship

bandwidth-delay limit = ( 2**16-1) / ( network delay) .

The significance of this relationship for emerging T-3 networks is illustrated in Figure 3, where published network delays [3] were used to graph the bandwidth-delay limits for transmissions between College Park, Maryland and various sites within the United States over ANSNET. As the figure shows, the limitations are severe for all except the Boston connection.

Case 2: Internet environment. Bandwidth-delay limitations are not yet a major factor on Internet communications within the continental United States. The reason: most Internet users are connected to the Internet with at most a T-1 rate connection. Current TCP can tolerate a delay of (Max window size)/(T-1 rate) = 64 Kbytes/192,000 bytes/sec = about 340 ms without bandwidth- delay affecting the achievable throughput. In other words, unless the Internet delay is at least 340 ms, the transmission will not be bandwidth-delay limited under current TCP. On the Internet, delays within the continental United States typically do not approach the 340 ms figure. However, Internet transmission rates, while not typically bandwidth-delay limited, frequently fall very short of the physical link capacity. Figure 4 shows the results of a three-week Internet data collection for which 5 megabyte digitized x-ray images were transmitted from the University of Arizona (Tucson) to NLM, using the standard File Transfer Protocol (FTP) tool, which uses one TCP connection for data transfer. The files were sent at 15-minute intervals. The graph shows the mean transmission time observed at each hour of the day. The horizontal line shows the transmission time expected based on the physical throughput capacity (192,000 bytes/sec) of the link. If the transmission achieved full link capacity, the file-to-file transmission time should have been 27 seconds for link transmission, plus approximately 6 seconds for file I/O time, giving a total of 33 seconds, as compared to FTP overall mean file-to-file transmission time of 150 seconds.

Accounting for the lost performance, both in the dedicated link case and in the Internet case, and developing technical methods to regain it is the crux of our research. Obviously, we may not expect to regain performance losses due to real congestion on the Internet; but, surprisingly, as we shall explain, it appears that much of the degraded performance in our Internet tests is not due to actual congestion, and is in fact recoverable using transmission alternatives to FTP.