Parallel TCP: How much slow does it take to add up to fast?

by Seth Noble |  Blog |  Dec 14, 2018

There are many vendors who claim to offer "accelerated" data transfer that is built on or compatible with existing TCP standards.  If you dig into their technical details (when they offer technical details), what they are almost always doing is splitting files amongst multiple parallel TCP sessions.  Sometimes misnamed "multithreaded" TCP, parallel TCP is one of that technology's most basic optimizations.  It has been a common workaround for TCP performance limitations since web browsers implemented it nearly a quarter century ago.

The primary use in web browsers is to improve the display of data from many different source files.  Outside of browsers, parallel TCP is also commonly used to transfer individual files by breaking them into separate chunks.  But splitting a file across multiple parallel sessions is only beneficial when certain conditions are met:

1. Latency is high, but congestion is low; and
2. Devices at one end or the other favor, or at least don't penalize, parallel access; and
3. The overhead of splitting and reassembling the file is low.

AWS S3 multipart upload is a good current example of parallel TCP, meeting all of these conditions when moving large objects within the AWS network.  The S3 architecture is heavily optimized for parallelism.  Individual sessions are slow to start and limited to at most a few hundred megabits per second (much less across the internet).  Breaking a large object into chunks and sending it via independent S3 sessions allows the S3 infrastructure to process and store those chunks across separate hardware.  As long as the object is sufficiently large, the cost of logically combining them into a virtual object at the end is less than the gain from splitting it up.

But for transferring data across the internet, where congestion is common, devices rarely favor parallelism, and combining data chunks in storage is slow, parallel sessions rarely provide more than modest benefits.  Even in the best case, parallel TCP requires careful manual tuning of the number of sessions to come anywhere near to full utilization of a fast path.  With everything that favors multipart upload for S3, it still chronically falls short of the network's potential for both internet and even private WAN paths.

Parallelism is ultimately just a workaround for the limitations of TCP and the devices that support it.  To actually solve those limitations and reliably get the full speed out of a WAN path requires stepping away from TCP entirely.  More of a slow thing is just no guarantee of a fast thing.  The Multipurpose Transaction Protocol (MTP/IP) technology behind all of our software has no TCP dependencies.  It doesn't need parallel sessions because it doesn't have TCP's limitations.

Is parallel TCP better than single TCP?  Usually.

Does parallel TCP really accelerate data transfer to the full speed of a WAN path?  Rarely.

Does MTP use parallel sessions?  No, it doesn't need to.

Our CloudDat for AWS product uses MTP to ensure high speed across the internet into AWS, avoiding TCP until the last hop into S3.