The reason a TCP connection generate retransmission
My question is why a TCP flow make a re-transmission when a network has enough link bandwidth.
For finding a cause, I used a wireshark. I got the below captured at a host side (10.0.0.1)
85968 47.896188899 10.0.0.2 10.0.0.1 TCP 66 50012 → 47178 [ACK] Seq=1 Ack=18321446 Win=16744448 Len=0 TSval=2453843 TSecr=2453843
86020 47.913068662 10.0.0.1 10.0.0.2 TCP 64578 47178 → 50012 [PSH, ACK] Seq=18321446 Ack=1 Win=29696 Len=64512 TSval=2453847 TSecr=2453843
86076 47.922372390 10.0.0.1 10.0.0.2 TCP 866 [TCP Retransmission] 47178 → 50012 [PSH, ACK] Seq=18385158 Ack=1 Win=29696 Len=800 TSval=2453850 TSecr=2453843
86088 47.922754778 10.0.0.2 10.0.0.1 TCP 66 50012 → 47178 [ACK] Seq=1 Ack=18385958 Win=16744448 Len=0 TSval=2453849 TSecr=2453847
86134 47.926332300 10.0.0.2 10.0.0.1 TCP 78 [TCP Window Update] 50012 → 47178 [ACK] Seq=1 Ack=18385958 Win=16776192 Len=0 TSval=2453850 TSecr=2453850 SLE=18385158 SRE=18385958
As the above, the packet with seq # 18385158 was re-transmitted although the host seemed not to send packer with the seq #.
Therefore I decided the packet loss occurred between layer 3 and layer 4 in the host.
I think there is a wrong part in the transmission process of the kernel.
But it is hard to analyze the more detailed.
Could you give me a little hint?
Thank you so much for reading.
Yes the host did: 18321446 + 64512 = 18385958, which is 800 octets further than the sequence number in the next packet: 18385158, so this is a retransmission of the last 800 octets. The ACK for 18385958 is in the next packet. It feels like we're missing an SACK from 50012 -> 47178 ?
@Jaap I really appreciate your comment. But I couldn't understand your words, due to lack of my understanding about, maybe SACK. I try to understand your words after studying. Thank you so much!
@Jaap Thank you for your explanation! If you don’t mind, could you check my understanding? The host at port 50012 receive SACK(18385158, 18385958). Then the packet the host send with seq # (18321446, 18385158) is lost. Is it right?
On first line .2 hosts ACK number is 18321446 then .1 host sends 64512 bytes + 800 bytes. This should bring the ACK number to 18386758 (18321446 + 64512 + 800) But .2 host ACKs 18385958 (18321446 + 64512) so it did not receive the last 800 bytes segment.
@Spooky I totally understand! :) I really appreciate you. Then could I conclude the two?, "(1) .1 host lost its packet with seq #18385158 maybe at its kernel. and .1 host re-transmit it. (2) because .2 host only send ACK 18385958 , .2 host did not receive the last 800 bytes segment. we guess the last 800 bytes are also lost. Thank you so much again.