Problem Description: Slow FTP Download Speeds
The issue of Slow FTP Download Speeds was reported by a user who observed that two clients were connected via a long-distance dedicated line with a round-trip time of approximately 36 ms. When uploading files via FTP from client 251 to client 179, the speed was a satisfactory 3.5 MBps, indicating no problems. However, when downloading files via FTP from client 179 to client 251, the speed significantly dropped to just 538 KBps, much slower than anticipated. Captured packet data revealed numerous instances of “TCP Dup ACK,” “TCP Retransmission,” and “TCP Out-Of-Order,” contributing to the Slow FTP Download Speeds.
Problem Analysis: Investigating TCP Issues
Basic analysis validated the initial observations, revealing two TCP streams within the packet data: one for the FTP control connection on port 21 and another for the FTP data connection on port 20.
The packets were captured on client 10.240.12.251, with an IRTT of 0.036169000 seconds. The session rate was 3950 bps, approximately 493.75 KBps, aligning with the reported figures.
In-Depth Analysis: Packet Loss and Retransmission
Further examination of the analysis revealed noticeable packet loss and retransmission issues.
Data transmission from 10.224.180.179 to 10.240.12.251 exhibited signs of retransmission and out-of-order packets.
Incremental time observations highlighted three significant delays: two were from the sending end (346 ms for packet 111 and 336 ms for packet 1446) and one from the receiving end (199 ms for the ACK from 10.240.12.251).
Upon reviewing packet 111, considering the IP ID changes and the RTT of 36 ms, the analysis indicated that the 346 ms delay was due to a retransmission timeout of 300 ms caused by packet loss, suggesting that packet 111 was likely a retransmission. Additionally, packet 112 exhibited a 200 ms delay due to delayed ACK.
Packet 1446 mirrored the issues found in packet 111.
Summary: Root Causes of Slow FTP Downloads
In conclusion, the slow FTP download speed from client 179 to client 251 can primarily be attributed to packet loss, retransmission timeouts (twice), and a single delayed ACK from the receiving end.