0

In the following wireshark trace, the packet with seq=41030 was sent, after some time the packet before it got acknowledged. after that a retransmission happened the packet seq=41030, then 3 ACKs received which indicated that seq=41030 is lost and should be retransmitted, but that doen't happen.
I'm confused, why retransmission happened before the receiving of the 3 ACKs. was the retransmission from a timeout? but why it wasn't retransmitted again when 3 ACKs received. enter image description here

Improve this question

1 Answer 1

Reset to default
0

What you see is basic TCP that has nothing to do with the number of Acks, because at its most basic TCP works based on timeouts. Hence, the TCP segment with sequence number 41030 was lost, never ack'ed, timed out and re-transmitted.

Detecting three duplicate ACKs is an optimization to speed up packet loss detection. The reasoning is that one segment was lost, but subsequent segments didn't and still trigger ACKs, but because the receiving side cannot acknowledge beyond the lost segment, so the assumption this is lost.

In your example you do see three ACKs for the same sequence number, but that will not trigger a retransmit, because they actually ACK everything that was already sent. The two last ACKs are not triggered by any incoming packets but self-triggered to update the receive window size. You typically wouldn't see that message on a heavily active TCP session, only on an idle one.

Improve this answer
4
  • I understood you the first part, i tried another trace and I received a clearly 3 duplicate ACKs (ack=86379) this time and still there is no retransmission. i.stack.imgur.com/nqJuJ.png
    – 0xDEADC0DE
    May 2, 2020 at 19:36
  • Sure, note that fast retransmit is simply an optimisation and actual implementations may vary, they may simply be preparing the retransmit and cancel it when the ack arrives anyway, or did checks against in flight messages that faiiled, or avoid a second retransmit, or... .
    – KillianDS
    May 2, 2020 at 20:47
  • That makes sense now.
    – 0xDEADC0DE
    May 2, 2020 at 21:57
  • Actually, it was as you said. In the previous screenshot, After the 3 DUP ACKS, there is an ACK packet (ack=93579) which acknowledges all previous packets including seq=86379. So the fast transmission was canceled.
    – 0xDEADC0DE
    May 3, 2020 at 1:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.