Not sure why the payload is smaller though. My best guess here is that TCP doesn't want to flood the network with a bunch of retransmissions for a given tcp connection/stream if it isn't getting an ACK for the first lost packet until some timer is past. Its initial retrans was #3779 with delta from original packet of 16.5s and its payload was only 12 bytes versus 600 byte payload of original packet. My (incorrect) assumption was that this packet should have similar RTO and would be retransmitted about same time first dropped packet was retrans, but it was not. Second dropped packet is #3666, which is put on the wire 29us after first dropped packet (#3664). OK this is a lot closer to double backoff but the payload is smaller, subset of original payload (524 bytes versus 1448 bytes). Shouldn't this double up and have been 1.2s? Third retrans for this first dropped packet is #3775 with 1.9s delta from #3774.
The second retrans for this packet is #3774 with 984ms delta from #3773. Since cable was pulled in this example there was multiple successive packets dropped from server to client that ulitmatley did not get any ACK, so RTO fired.įirst dropped packet is #3664 and its initial retransmission is 621ms later packet #3773. In this trace, which was just an FTP GET between two hosts and I pulled the cable on the client in the middle of the transfer, I have some questions as to TCP Retransmission behavior that hopefully someone can help me better understand.
0 kommentar(er)
