As Giuseppe notes, if running TCP, a common problem is the receiving host doesn't advertize a large enough receive window to allow a TCP flow to ramp up to full link bandwidth. Ideally you want the receiving host to advertize a window that supports the path's BDP (bandwidth delay product).
Assuming your bottleneck is at the branch, and is 100 Mbps, and the RTT is 100 ms, the BDP is 100,000,000 (bps) * .1 (sec) / 8 (bits/byte) = 1,250,000 (or about 834 1500 byte packets).
Since TCP sends its outbound send window at line rate, you also need to insure network devices can buffer these bursts.
Another issue is TCP slow start. Depending on RTT, it can take some time for TCP to hit full speed. Any drops might force TCP back into slow start or congestion avoidance, the latter being very slow to increase bandwidth.
Besides increasing the receiving host TCP receive window, if doing large bulk data transfers, dedicated transfer applications that split the data transfer into multiple concurrent TCP flows can often utilized full link bandwidth and get to it faster without needing to modify the receiving client.
Another option is usage of some type of transparent WAN acceleration product between the sending and receiving hosts. Many different techniques can be used by them. (One interesting technique is "spoofing" the receiving host's buffer size to control sender's transmission rate.)
PS:
One disadvantage of changing the receiving host's TCP window is that the change is often global when you really want it just set for specific TCP flow. If the receiving host's is larger than path's BDP, it will cause the sending host to send bursts larger than the path can accept. If FIFO queuing is in use, the sender might be driven again and again into slow start, causing very poor transfer performance. RED might improve this since the flow will more likely drop into congestion avoidance.
