Optimization of Network Parameters for “Just-In-Time” Radiology Study Interpretation Over an Enterprise Wide Area Network
 
Authors:
Colin M. Segovis, College of Medicine, Mayo Clinic; Todd L. French; Steven G. Langer, PhD
 
Hypothesis:
We hypothesized that using other application layer protocols, such as hypertext transfer protocol (HTTP), file transfer protocol (FTP), or network file system (NFS) that are considered less “chatty” than common internet file system (CIFS), or modifying the default CIFS parameters would decrease radiology study transfer times over a wide area network (WAN). We also hypothesized that modifying internet and transport layer parameters, such as packet size, could decrease file transfer times.
 
Introduction:
The demands of a multi-site high through-put radiology practice with significant geographic separation between the PACS server and the interpretation workstation have forced us to move away from traditional teleradiology models. The workload needs to be distributed to geographically separate radiologists, but image study interpretation must be rapid to meet clinical demand. Thus, we have begun to explore “just-in-time” image pulls from a PACS, regardless of the distance between the server and the interpretation workstation. The speed of these image pulls is greatly dependent on the network connectivity between the server and the interpretation workstation, which are connected over a WAN, and the current speed of these transfers across the enterprise WAN at our institution has proven inadequate for the needs of our practice.

Two variables that determine the speed that data can move between two points on a packet switched network are the latency between the points and the network protocol used to connect the two points. Latency is a function of distance and can be considered a constant when evaluating data transfer between two points. Network protocols used on today’s packet-switched networks can vary, however. Each network protocol has an inherent amount of “chatter” as data move from one point to another. The chatter consists of communication between points that enables data transfer to occur. The “chattiness” of DICOM makes it difficult to use over a WAN. CIFS is a widely used network protocol and part of the foundation of the Samba file sharing system. Furthermore, CIFS/Samba is easy to use, stable, and works with a large number of client operating systems. CIFS has been used to transfer imaging studies between server and client to avoid transfer delays associated with the “chattiness” of DICOM. CIFS is a “chatty” protocol, however, and may not be the optimal transfer protocol to use when transferring radiological studies between a PACS server and interpretation workstation over a WAN. Other common application layer protocols, such as HTTP, FTP, and NFS that are less “chatty,” may prove superior as network protocols for “just-in-time” image pulls for image study interpretations across an enterprise WAN.

 
Methods:
A network was created with a Linux client and server serving as endpoints. Those devices were connected through a Simena network simulator that permitted modification of the roundtrip latency between the two endpoints. This experimental setup allowed us to simulate geographic separation by varying latency. Round trip latency was set at values ranging from 0.1 ms to 800 ms, while experimenting with various application protocol types (CIFS, HTTP, FTP, and NFS) and parameters (CIFS receive buffer size, packet size) to determine the effect of transfer time of a 1024 kB data stream. Furthermore, this experimental design allowed us to test the effect of modification of internet and transport layer protocols (packet size) on transfer times at various roundtrip latencies.
 
Results:
The time to transfer 1024 kB of data was 67.3 seconds using a default CIFS/Samba setup with 800 ms of round trip latency (Figure 1). Transfer time for the same data decreased to 27.7 seconds, 31.2 seconds, and 16.8 seconds for HTTP, FTP, and NFS, respectively (Figure 1). Increasing the receive buffer size of CIFS/Samba on the client and server in the experimental setup from the default 16 MB to 64 MB decreased data transfer time from 67.3 seconds to 48.9 seconds (Figure 2). Interestingly, if the TCP/IP packet size was increased from 1500 bytes to 9000 bytes, then CIFS/Samba transfer times did not significantly change (Figures 1 & 2). Transfer time was decreased however, by combining a 64MB CIFS receive buffer and 9000 byte packet size. Transfer times decreased from 68.2 sec with 16MB buffer/9000 byte packets to 24.1 sec with 64MB/9000 byte packets (Figure 2). Surprisingly, NFS was the only other application layer protocol tested that substantially benefited from increased TCP/IP packet size: transfer time at 800 ms round trip latency was 16.8 seconds with a packet size of 1500 and 10.4 seconds with a packet size of 9000 bytes (Figure 1). Furthermore, TCP/IP packet size did not have an effect of NFS mediated transfer times until round trip latency was greater than 500 msec.
 
Figures 1 and 2
 
Discussion:
Network models used in traditional teleradiology have proven inadequate for “just-in-time” image study transfers required by the high-throughput radiology practice at our institution. Our data demonstrate that of the parameter tested the NFS application layer protocol combined with a 9000 byte TCP/IP packet size provide the fastest transfer times of a 1024 kB data stream. Furthermore, these data suggest that NFS with a TCP/IP packet size of 9000 bytes should result in faster “just-in-time” image pulls between a PACS server and client across an enterprise WAN compared with other application layer protocols and default internet/transport layer parameters.
 
Conclusion:
NFS with a TCP/IP packet size of 9000 bytes should be considered when designing networks for “just-in-time” radiology study interpretation over an enterprise WAN.