High latency Links

Question

We have a branch office that has about 220ms of latency between it and head office. The branch is composed of about 15 client machines (Windows 7 desktops and laptops). We have been struggling with application performance across this link. The Branch office has a 2Mbps MPLS connection and head office has a 50Mbps MPLS connection. Because of the Latency and BDP we get horrible throughput and rarely reach 2Mbps. Increasing the bandwidth to this site would not have much affect I don't think. One thing that was suggested was getting a second 2Mbps MPLS connection there and routing certain traffic over each each pipe. Idea is that we can double the throughput by having 2 separate pipes rather than 1 larger pipe.
My question is, does anyone have any experience with this sort of setup? Will this improve overall performance to the site?

Answer 1

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Yes, I have lots of experience (supporting international WAN links).
No, I don't see a 2nd pipe being better than one twice as large.  If fact, it can be detrimental.  However, the killer in these situations is the distance based latency which isn't "fixed" by adding bandwidth.
For distance based latency, there's no 100% "fix" beyond "just don't do it".  If possible, use local resources especially for "interactive" network access.  WAAS/WAFS, with their "tricks", can mitigate much of the distance latency impact (basically the most benefit comes from local caching which avoids the WAN's RTT).
For long distance throughput, you want to avoid any drops (because of slow error recovery) and need to have (for TCP apps) the receiving host's RWIN support (available) BDP.  This is difficult to manually optimize, although often, on older hosts, you need to increase their RWIN to allow a TCP flow to utilize all available bandwidth.  Again, WAAS/WAFS or dynamic traffic shapers can do "tricks" to optimize throughput (basically they often spoof the connection across the WAN link so you don't need to adjust a host's RWIN).
QoS can keep bulk transfers from disrupting interactive applications, which can make a noticeable improvement.
Bulk transfers, w/o WAN acceleration, can be faster if concurrent flows (not multiple links) are used.  This because the high distance based RTT slows how fast a TCP flow will initially increase it's flow rate and/or (especially) recover its transmission rate when there's packet loss.
PS:
BTW, different hosts, with different "vintage" TCP stacks and/or file processing logic, can fare quite differently across a high latency network.