I have two captures: a sender side capture file and a receiver side capture file.
When I applied the tcp.analysis.lost_segment filter at sender side, I didn't see any frame popping up. When I applied the same at receiver end and saw the black highlighted columns matching the description as "Expert Info (Warn/Sequence): Previous segment not captured (common at capture start)".
- Who knows first (sender or receiver) that the packet is lost?
- Scrolling at the sender side. I do see frames highlighted in black
with info as, "This is a TCP duplicate ACK." Is this a lost packet?
But this frame is different from the one at the receiver saying, "prev
seg not captured." - Which capture file should be used to identity the lost packet?
Best Answer
Actually, in networking you never know if a packet got lost or not if you are only watching the end-points. This is due to the fact that you cannot distinguish between a lost packet (dropped by router or even corrupted on the link layer) and a extremely delayed transmission (packet is still on the wire or in a queue but is not processed).
A TCP duplicate ACK indicates: You received an acknowledgement from the server but it gives the same sequence number that the last ACK had. This means that an intermediate packet is lost (as the receiver ACKed the number twice) or extremely delay. But as you have received another ACK (the duplicate ACK) this means that the network path is not completely congested. Consequently, if you get multiple ACKs in a row, you can assume that the ACKed packet is lost as the other packets come through. Many TCP implementations then do what is called a Fast Retransmit, so that they don't wait for the retransmit timeout but instead resend the first unacked packet. This also has some implications regarding the congestion window.
The message "Expert Info (Warn/Sequence): Previous segment not captured (common at capture start)" means the following: On the receiver side you capture an outgoing ACK packet for a sequence number where you haven't seen the respective segment. This is common, as it might be possible that a segment arrived, you started the capture and afterwards your TCP stack replied with an ACK. So there was no way to see the incoming packet. This does not necessarily indicate a loss.