TCP Retransmission Behavior

I have uploaded a sample trace to: http://www.cloudshark.org/captures/b6c6ccb4d513

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.

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.

First dropped packet is #3664 and its initial retransmission is 621ms later packet #3773. The second retrans for this packet is #3774 with 984ms delta from #3773. 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. OK this is a lot closer to double backoff but the payload is smaller, subset of original payload (524 bytes versus 1448 bytes). Why is this so?

Second dropped packet is #3666, which is put on the wire 29us after first dropped packet (#3664). 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. 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 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. Not sure why the payload is smaller though.

This leads me to my last question, which I believe must be tied to the answer. Wireshark shows in its TCP Analysis Flags section of a retransmitted packet that the RTO is based on a delta from a certain frame, which is usually not the frame of the original lost packet. It seems to be based on a frame at the end of a "train" of data or more likely a full tcp window of data sent. I looked at RFC 2988 and it's not clear to me how often the RTO timer is applied. Up until now I thought each packet had its own RTO timer but now I'm not so sure anymore. If anything I'm more confused.

(5.1) Every time a packet containing data is sent (including a retransmission), if the timer is not running, start it running so that it will expire after RTO seconds (for the current value of RTO).

(5.2) When all outstanding data has been acknowledged, turn off the retransmission timer.

(5.3) When an ACK is received that acknowledges new data, restart the retransmission timer so that it will expire after RTO seconds (for the current value of RTO).

I think the "if the timer is not running, start it" is making me think differently or maybe I'm just thinking too much about it.

I appreciate any feedback on this. I thought I understood this better than I do and hope this isn't too much a a newbie question.

Kind Regards