TCP Retransmission / TCP Dup ACK

TCP by design is considered a reliable protocol since it keeps track of the data it transmits with sequencing and acknowledgements. And hence some times when a network is congested / saturated or there is a faulty component somewhere between the source and destination causing packet loss it is necessary to re-transmit a specific sequence again.

TCP retransmission occurs when the sender sends a TCP segment (which has a specific sequence number associated with it), the sender uses a timer to determine how long it should wait before hearing back (receives an ACK) from the segment it has sent - if the timer elapses before hearing anything back it will send a re-transmit the segment - an example capture is show below:

On the other hand the same situation can occur on the receiver side when the receiver receives a segment with a high sequence number than it is expecting - so the receiver send what is known as a TCP Dup ACK - that simply instructs the sender that it is expecting sequence 7 (not 8 or 9) for example. The receiver will also sometimes send a second TCP Dup ACK that will invoke Fast Restransmission - where the sender will retransmit the segment without waiting for the retransmit timer to expire.

As stated above this is quite often due to congestion on a network - but can also be due to faulty components such as NIC's, faulty or loose cables etc. If possible it is best to narrow down the problem area by checking each hop of the source / destination pathway for any problems - e.g. checking interface statistics for dropped / malformed packets on the router / switch.