|
IPSec VPN and DSL PerformanceHome Contact IFM |
Bandwidth and Latency. These two words have a lot to do with how fast your Internet connection or VPN are.
Bandwidth is basically the volume of data you can get (often measured in kilobits per second [or kb/s]), and latency is how long it takes to get to you (often measured in milliseconds [or ms]). The best mix is high bandwidth with low latency.
But what happens when you have high bandwidth with high latency? In an ideal world, nothing should change - you should still get lots of data; it should just take a little bit longer to come to you.
Alas, due to an issue with the Windows TCP/IP stack, this doesn't happen. What actually happens is you get a whole lot of data coming towards you, and then a short pause - when the circuit should be continuously pumping data. As a result, the overall throughput starts dropping.
As an example, lets pretend you had two Windows 2000 machines on a 100Mb/s Ethernet segment. If the latency on the circuit was 1ms, then the maximum throughput you can get is 95Mb/s. If the latency on that same 100Mb/s network increases to just 10ms, then the throughput between the machines will drop to just 14Mb/s (this is why you need good quality LAN switches!).
DSL, is by nature, a comparatively high latency, high bandwidth service - the two things that you don't want to mix together for a Windows system. IPSec, as used for VPNs, makes the problem even worse, because the data flow practically stops while data is being encrypted, a micro pause, if you like.
So how can you work around this issue? The most effective technique I have found is to increase the Windows "TCP Receive Window" size. A great tool for doing this is DrTCP. What this does is allow Windows to receive data in bigger chunks, there by reducing the net delay over the duration of a transfer. For DSL and IPSec VPNs in New Zealand, I recommend a "TCP Receive Window" of 65535 bytes. DrTCP allows you to change many other parameters - but I suggest you don't touch them. Note that after changing the "TCP Receive Window", you'll have to reboot your machine to make the changes take effect.
Once Caveat is that this setting has the most effect on good DSL connections, such as 4Mb/s downstream or better. The smaller your connection (less bandwidth), the less the effect will be. The greater your downstream speed, the better the result.
Using a Cisco 827H with firewall enabled with a downstream speed of 7.6Mb/s, I was able to achieve a throughput of 250kb/s. After modify the "TCP Receive Window" the throughput increased to over 400kb/s.
Once thing to note in New Zealand, is that there is a constraint on the JetStream network that effectively limits transfers between a single pair of IP addresses to 4Mb/s. So if you kick off two downloads to the same site at the same time, your total throughput will remain the same, and the transfer rate of each transfer will halve (assuming the site has a big enough connection to saturate your connection). However, if you start off two downloads from two different sites, then you can achieve up to 4Mb/s from each (once again, assuming both sites are capable of sustaining such a transfer rate).
This is where you can see huge performance improvements. I setup two Cisco 827's, and established an IPSec VPN between them. I transferred data from one end to the other using the HTTP protocol. Initially I got transfer rates of 320kb/s. Previously, this is the maximum throughput I had been able to achieve. After making the change, I found I was able to start 2 simultaneous transfers, with both running at 320kb/s, to give a net throughput of 640kb/s. Then I tried running three sessions at a time, and managed to get 800kb/s. At this point, the CPU in the 827 was flat lining at around 95% utilization.
Then I tested file transfers using the SMB protocol (like the method used by Windows Explorer to copy a file). Initially I has able to get about 50kb/s (far less than HTTP - obviously Windows file sharing isn't very efficient with high latency ...). After making the modification the throughput lifted to around 128kb/s.
If you are using DSL for Internet access, and you have a downstream speed of 4Mb/s or better, then I recommend you modify the "TCP Receive Window Size" to 65535 bytes.
If you are using IPSec, then I strongly recommend you modify the "TCP Receive Window" size to 65535 bytes, due to the latency caused by encryption.
References: