Troubleshooting slow FTP speed

Question

client 10.240.12.251(as C251) and client 10.224.180.179(as C179) connected with 30M long distance leased line, with round-trip time 36ms. when upload from C251 to C179 via FTP, speed will be 3.5MBps, it's fine. while download from C179 to C251 via FTP, speed drop to 538KBps, it's hard to accept it. the download session is captured and uploaded to cloudshark @: https://www.cloudshark.org/captures/458343b01b3c it seems that thare are many "Tcp Dup Ack", "TCP Retransmission" & "TCP Out-Of-Order"

it's really appreciate that anyone can help to find the root cause, thanks.

Answer 1

0

The root cause is packet loss and a relatively high retransmission timeout at the sender combined with a delayed_ACK at the receiver.
There are 3 instances where the transmission stalls, twice because of the 330 ms RTO at the sender and once due to the 200 delayACK timer at the receiver

(frame.number>109&&frame.number<113)||(frame.number>1444&&frame.number<1447)

alt text

answered 09 Oct '15, 08:19

mrEEde
3.9k●15●22●70
accept rate: 20%

edited 09 Oct '15, 08:20

Hi MrEEde, a few observation here, packet 111 is not retransmission and looks 346 ms delay here could be due to APP(FTP), and about packet 1446, even here 340 ms delay doesnt looks to be due to RTO bcause due to sack enabled sender has the information to make intelligent decisions about which packets to retransmit.

(10 Oct '15, 03:48) kishan pandey

Having a trace at the receiver only we and wireshark cannot recognize packet 111 as a retransmission (as we didn't see the original transmission arriving). Still my bet is that - if we took a trace at the sender - we would see this sement being sent twice .

Packet 1146 is in fact flagged as a retransmission with tcp.analysis.rto gt 0.3 arriving with a delay of 336 ms after 1444 (which already was a retransmission... So - with an RTT of 36 ms - this is too close to the default MinRTO 300ms of the windows server to be coincidental ....

(12 Oct '15, 03:13) mrEEde