This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP retransmission analysis problem with Wireshark

0

I'm using Wireshark to analyze capture file dumped with tcpdump, but I can't understand some results as follows:

(1)Fast retransmission. In my opinion, fast retransmission will happen while receiving 3 same duplicate acks, but in reality it happens after dozens of or even more than one hundred acks have been received.

3660 6.364478 TCP 94 [TCP Dup ACK 3380#140] 37595 > http [ACK] Seq=1 Ack=3214429 Len=0
3661 6.365102 HTTP 1494 [TCP Fast Retransmission] http > 37595 Seq=3214429 Ack=1 Len=1428

(2)Weird retransmission. I've found retransmission happend after being acked. Maybe due to SACK?

10041 18.681817 TCP 86 [TCP Dup ACK 10015#13] 37595 > http [ACK] Seq=1 Ack=9180613 Len=0(SACK: 9099217-9100645 9182041-9217741)
10042 18.683154 HTTP 1494 [TCP Retransmission] http > 37595 Seq=9127777 Ack=1 Len=1428

(3)Out of order. This is a question that has been asked by Janis Bishop. I can understand that receiver end can receive out of order packet due to multi route path, but why can the sender end send out of order packet?

10036 18.678996 HTTP    1494 http > 37595 Seq=9216313 Ack=1 Len=1428
10037 18.679020 TCP 78 [TCP Dup ACK 10015#11] 37595 > http [ACK] Seq=1 Ack=9180613 Len=0
10038 18.680609 HTTP    1494 [TCP Out-Of-Order] http > 37595 Seq=9066373 Ack=1 Len=1428
10039 18.680642 TCP 86 [TCP Dup ACK 10015#12] 37595 > http [ACK] Seq=1 Ack=9180613 Len=0
10040 18.681794 HTTP    1494 [TCP Out-Of-Order] http > 37595 Seq=9099217 Ack=1 Len=1428

I did the capture at the server end(also as the data sender).In my situation, the client end(as data receiver) send request to the server, then the server send data back.

asked 11 Mar '14, 00:45

kikita's gravatar image

kikita
11113
accept rate: 0%

edited 12 Mar '14, 20:59


One Answer:

0

1) Usually, the reason why you see is tons of DUP acks before the fast retransmission comes in is that you're close to the destination of the lost packet, which means the distance is very short. Keep in mind that your 3 dup acks need to travel half the RTT to the sender, and then the retransmission needs to come back to you (another half RTT). That way your receiver keeps pumping out dup acks while the fast retransmission process takes one full RTT (plus a bit more) to get processed. And that is in situations where everything else is working fine. If you have bottlenecks in your network you can see tons of dup acks sent out before receiving the retransmission; I just broke a record in a case I analyzed recently where there were more than 1000 duplicate ACKs for one single lost packet...

2) this can happen to, e.g. if the ack didn't make it to the server, or for any other reason. To diagnose that you'd need a capture taken simultaneously close to the other node.

3) It does not have to be a multi route path. Depending on prioritization and buffer management in routers and other devices packets sometimes get forwarded earlier than those already waiting in line. Generally speaking, senders do not send out packets out of order, they get mixed up on the way. If you capture at the sender and see out of orders coming out you've got something very unusual, which would require further investigation into the TCP stack...

answered 11 Mar '14, 03:57

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks very much.

I did the capture at the server end(also as the data sender).In my situation, the client end(as data receiver) send request to the server, then the server send data back.

So question 2 is still weird, the capture information reveals that the server has received ack to seq(9180613), which is higher than seq(9127777), but server still send back packet begun with seq(9127777), which is not needed. From the ack(to seq 9180613) packet's detail information in the option segment(SACK: 9099217-9100645 9182041-9217741), does this mean that packet begun with seq(9100646) is still not received indeed?

Question 3 is indeed unusual, and it has also happened before in the link above.

(11 Mar '14, 20:31) kikita