Solving the Problems of TCP
The FileCatalyst accelerated file transfer protocol offers incredible speed gains versus traditional file transfer methods. FTP and HTTP are based on TCP/IP, the backbone of the internet. For loading a webpage, TCP is great; however, for sustained data transfer, it is far from ideal.
Have a look at the following chart. Even though the line speed is 100Mbps, transfers are much slower. With fast connections, latency and packet loss bring TCP-based file transfer to a crawl.
The time it takes to send a packet and receive an acknowledgment is called the round trip time (RTT) or simply the “latency”. TCP is serial in nature, meaning that the next piece of a file won’t be delivered until the previous one is acknowledged. This creates a period of “dead air”. The higher the latency, the more dead air.
Now imagine spending more time waiting for acknowledgments than sending data. The amount of data that can be sent before waiting for acknowledgment is governed by a mechanism called the “TCP Sliding Window”. The window closes aggressively when congestion is detected, and opens to its maximum quite slowly. TCP’s congestion detection throws many false positives, meaning that the window often closes without justification.
The resulting dead air means that with TCP, your practical transfer rate can be orders of magnitude slower than your line speed. Assuming packet loss of 0.1% and a line speed of at least 10Mbps:
- Once you hit 50ms of latency, your transfer speed starts to take a major hit
- By 80 ms, your maximum speed is 2500 Kbps—even for links 1Gbps and faster
- By 400ms—not uncommon for satellite connections—you are crippled at 500Kbps
The FileCatalyst protocol is able to offer such large speed gains over FTP because it is based on the UDP protocol, rather than TCP. Files can be transferred over the UDP protocol without being impeded by network impairments such as latency or “dead air”.