LFN - issues

http://www.riverbed.com/docs/TechOverview-Riverbed-RiOS.pdf
http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/
http://en.wikipedia.org/wiki/HSTCP
http://tools.ietf.org/html/rfc1323
http://en.wikipedia.org/wiki/Bandwidth-delay_product
http://en.wikipedia.org/wiki/Round-trip_delay_time
http://community.riverbed.com/t5/Steelhead-Appliance/hs-tcp-questions/td-p/5564
http://cisconet.com/traffic-analysis/traffic-analysis-general/413-internet-speed-issue-why-tcp-window-size-is-matter.html
http://www.networkworld.com/details/7591.html
http://research.microsoft.com/en-us/um/people/padhye/tcpworkshop/slides/raj_jain_high_speed_tcp.pdf
http://icfamon.dl.ac.uk/papers/DataTAG-WP2/reports/task1/20021001-Yee.pdf

WAN Acceleration hardware (and software) from vendors like Riverbed and Cisco have methods to optimize "Elephants" (LFN's or Long Fat Networks).

In Riverbed's case they combine TCP acceleration techniques, such as "Virtual Window Expansion (VWE)" or normal WAN links, but for LFN's (long-haul, high-latency links such as satellite) you can enable HS-TCP (High-Speed TCP - see RFC 3649). When using HS-TCP you need to calculate Bandwidth Delay Product to set the buffers.

VWE is a product of the use of "Scalable Data Reduction", or sending less over the WAN. SDR is not just compression, but clever use of storing data in bit-streams on WAN Accelerator disk and sending only "references" to that data when the same bitstream is requested over the WAN. SO it doesn't matter if the data is sent using FTP, CIFS or HTTP. Clever stuff.

In addition to optimising TCP, Other protocol-specific acceleration techniques can be used as well. "Read Ahead and Write Behind, MAPI pre-population.

The list goes on!