[TCP Previous segment not captured]
This is displayed when the "As far as we see the Seq#(sequence number) of the packet , a packet should be observed before this packet but not seen in Wireshark".
Cause of not capturing a packet before are perhaps two of either following.
- The packet before one is lost
- It has been received prior to the start of capturing
[TCP Dup ACK XXX # N]
The mark is displayed when "The same Ack#(acknowledgment number) is observed compared as the one before packet [which No. field on Wireshark is XXX] .
For example, when Ack# = 1000, it means " Next, I want to get the packet Seq#=1000 !" .If the opponent comes send this many times, it will be considered that he does not receive a packet of Seq # = 1000, and he requests a retransmission.
So, if this Dup ACK occurs frequently, it is probable that packet loss has occurred less frequently.
[TCP Fast Retransmission]
As above, when TCP Dup ACK is resent three times (four times including first sent), Fast Recovery Algorithm of TCP works and opponent resent the packet required with Ack# without waiting for the RTO (Retransmission TimeOut).This mark will be displayed in packet what wireshark believes to have been retransmitted by this algorithm (Dup ACK is the third and within RTO) .
Unlike the Fast, this mark is displayed when the packet after the RTO is received in a different order as the order of the Seq#.
"It is within the RTO of time, but Seq# is not in order" will appear this mark.
Next two reasons will be considered as cause.
- NW route was different for packets (for example, such as by Equal-Cost Multi Path) and really switched the order
- Before receiving three times Dup ACK, and prior to RTO, received the packet required with Dup ACK (it is unknown whether came late or retransmitted)
[TCP Spurious Retransmission]
This mark will be displayed when "in spite of returning the Ack, the packet has been retransmitted".
Although visible in Wireshark, is due to Ack packet is lost in a subsequent somewhere.