We have been doing a POC with one of our healthcare customers who are using radiation imaging using DICOM/PACS standards. We are evaluating benefits of WAAS with respect to this specific application. Expectations from the customer are two-fold:
a. Reduce the transfer time of images between application and endhost (radiation device)
b. Optimize WAN bandwidth and perform consistently with varying network performance (latency and packet loss)
Referring to this Cisco whitepaper on this topic: http://www-v6.cisco.com/c/dam/en/us/td/docs/solutions/Verticals/waasapnotes.pdf
POC is conducted with various features turned on in WAAS - 1. TFO only 2. TFO with LZ and LZ 3. TFO with DRE-adaptive
Observations are below:
1. TFO only - Could not see any benefit compared to without WAAS turn on
2. TFO and LZ - Could see benefits shown in WAAS CM (18% between original and optimized traffic). But there is no improvement on the transfer time. Also the peak bandwidth remains the same on the WAN
3. TFO, DRE adaptive and LZ - See huge benefits due caching - both on bandwidth savings and transfer time
Since customer would not typically re-transmit the same images multiple times in a day, caching is not applicable to customer network.
Below are the clarifications and recommendations that we seek after the POC:
a. With compression enabled, this would also improve the transfer time of images. We are not seeing it though. Can this be related to compression and decompression time taken by vWAAS which is off-setting the end to end WAN latency (50ms). Or any settings to be enabled to see transfer time improvements?
b. For TFO to be effective, do we have to increase the buffer size and window size?
c. Any recommendations on the WAAS settings specific to DICOM image transfer?
These are just my thoughts, but maybe you will find them useful.
* TFO in theory helps with applications / operating systems that dont setup TCP sessions for optimal use.
I suspect this depends on how the applications is coded, but in most cases the application would just use the operating systems included code for TCP setup. Like build-in HTTP support in the operating system.
It can be argued that newer operating systems do a better jobs of this then old ones. So compare Windows 7 and Windows 10 as a client and see if you get a difference?
There are options in "TCP Settings" where you can adjust the Optimized and Original side. Try using the "High BDP Recommended Values" for "high speed links" and see if you see a difference.
* LZ Compression
This is a basic non-lossy compression.
From what i can see online DICOM is just a container format (like TIFF) where you can select in the application if you want to compress or not. But almost all image software does at least the non-lossy compression on images, and in some cases lossy.
PACS is XRAY (very high resolution) over HTTP/HTTPS if im not mistaken?
If its over https, be sure to include the certificates on the WAAS else it will just be an encrypted stream.
HTTP(S) also can do GZ compression by itself (sniff the traffic on the client and see) that might already be compressing things.
But otherwise your data is almost guaranteed to be as compressed as possible in the application, any compression on the WAAS wont do anything other then add delay.
This is as you said only useful when seeing the data multiple times, but its likely the only benefit you will see.
Short: If im not mistaken XRAY data in PACS is image data thats already as compressed as it can be and still be lossless, and its sent over http/https. So there is little protocol overhead. If it was something like SMB, then the WAAS would speed up the protocol ACKs..
You are likely going to get better performance by making sure the server and client are the absolute latest version of operating systems. (2012 R2 or 2016 for server (if windows), and Windows 10 for client).
And then making sure the centrally located storage array connected to the PACS server is actually delivering the needed performance (9/10 when troubleshooting these kind of issues its the storage array slowing things down)