TCP is it possible to achieve higher transfer rate with multiple connections?

Question

Is it possible to achieve better data transfer rate with multiple parallel TCP connections in high-latency environment (public internet with large geographical distance assuming no traffic shaping per connection or stuff like that) or can TCP utilize the whole bandwidth with a single connection?

---

Is TCP sending data as fast as it cans if receiver doesn't report buffer congestion with 0 windows size? So if RTT is for example like 60 seconds it doesn't affect the rate at all? Is there some maximum window size or something else limiting the rate?

Answer 1

Yes, but not necessarily easy to implement. CDNs such as akamai make claim to part of their performance by compressing larger packets than would normally be sent because of their dedicated reliable pipe. Hard to give better detail without knowing more of your application.

Answer 2

If you're the only one on the link, it will increase overhead and decrease speed. However, when sharing a fully saturated link with others, it's a way to game the system and increase your overall speed (each connection will be slower than a single one, but the aggregate will be faster as you've now got a larger percentage of "time slots" (what's the technical term? It escapes me now) allocated to you).

Answer 3

One advantage multiple concurrent connections may give you (subject to the same caveats mentioned by dove and Brian) is you will be able to better overcome the problem of having too small a TCP receive window.

The principle this relates to is bandwidth delay product. (There's a more detailed explanation here).

A brief summary: in high-latency, high-bandwidth environments, reliable communications such as TCP are often limited by the amount of data in flight at any given time. Multiple connections are one way around this, as the bandwidth delay product applies to each connection individually.

In more detail, consider the following: you have an end-to-end bandwidth of 10^8 bits per second (10 megabits/second), and a round-trip delay of 100ms (0.1 seconds). Therefore, there can be up to 10^7 bits (10 megabits = ~1.25 megabytes) of data sent before the acknowledgment of the first bit of data has gotten back to the sender.

This will vary depending on the TCP stack of your OS, but a not-uncommon value for TCP receive window size is 64Kbytes. This is obviously far too small to allow you to make full use of the end to end bandwidth; once 64kbytes (512kbits) of data have been sent, your sending process will wait for a window update from the receiver indicating that some data has been consumed before putting any more data on the wire.

Having multiple TCP sessions open gets around this by virtue of the fact that each TCP session will have its own send/receive buffers.

Of course, on the internet it's difficult to determine the true available end-to-end bandwidth, due to TCP window size, contention, etc. If you're able to provide some sample figures, we may be able to assist more.

The other option you should look into is setting a larger receive window when you create your socket, either globally using an OS setting, or on a per socket basis using socket options.

Answer 4

Muz's description of the issue is spot on.

Keep in mind that taking advantage of it may depend on the implementation of TCP in your operating system. In particular, for best results you want a TCP stack that supports the Window Scale option from RFC 1323.

Further, you may need to tweak some OS settings to make this work. On Windows there is a Registry setting called TcpWindowSize that you may need to adjust. There is a Microsoft KB Article 224829: Description of Windows 2000 and Windows Server 2003 TCP Features that describes just how to do that.