Hi, TCP Fast Retransmit detection is explained as: / If there were >=2 duplicate ACKs in the reverse direction (there might be duplicate acks missing from the trace) and if this sequence number matches those ACKs and if the packet occurs within 20ms of the last duplicate ack then this is a fast retransmission / Why does the retransmitted packet have to occur within 20 ms of DUPACK? If you collect a trace on the sender, I could see this work, but in a receiver trace, or a trace from the network core, Fast Retransmit'ed packet can occur well after 20 ms of DUPACK. Thanks. asked 29 Aug '13, 08:53  instalater |
One Answer:
This is a somewhat arbitrary value that is hard-coded into Wireshark to try to distinguish between Receive Time Out (RTO) retransmissions and Fast Retransmissions. There isn't really a reliable way for Wireshark to determine what triggered a retransmission, so it's possible for Wireshark to mis-identify the type of retransmission. It's also possible for Wireshark to mis-identify out-of-order packets as retransmissions. You're right that a Fast Retransmission can show up more than 20 ms after the Duplicate ACK that triggered the retransmission. Normally, data would still be flowing, and Duplicate ACKs would keep being generated, so the retransmission would usually be within 20 ms of a Duplicate ACK, although not necessarily the Duplicate ACK that triggered the Fast Retransmission. This would not be true if the lost packet was near the end of the data stream and data has stopped flowing. It's also possible that Duplicate ACKs are being generated and showing up in the Wireshark trace, but are not making it to the sender due to some network problem. The sender will eventually send a RTO retransmission, but Wireshark will identify it as a Fast Retransmission due to the Duplicate ACKs. answered 29 Aug '13, 10:05  Jim Aragon |
