Ask Your Question

The reason a TCP connection generate retransmission

asked 2019-08-27 14:12:40 +0000

nimdrak gravatar image

updated 2019-08-27 14:31:36 +0000

grahamb gravatar image

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 (

85968   47.896188899    TCP 66  50012 → 47178 [ACK] Seq=1 Ack=18321446 Win=16744448 Len=0 TSval=2453843 TSecr=2453843
86020   47.913068662    TCP 64578   47178 → 50012 [PSH, ACK] Seq=18321446 Ack=1 Win=29696 Len=64512 TSval=2453847 TSecr=2453843
86076   47.922372390    TCP 866 [TCP Retransmission] 47178 → 50012 [PSH, ACK] Seq=18385158 Ack=1 Win=29696 Len=800 TSval=2453850 TSecr=2453843
86088   47.922754778    TCP 66  50012 → 47178 [ACK] Seq=1 Ack=18385958 Win=16744448 Len=0 TSval=2453849 TSecr=2453847
86134   47.926332300    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.

edit retag flag offensive close merge delete


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 gravatar imageJaap ( 2019-08-27 14:42:12 +0000 )edit

@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!

nimdrak gravatar imagenimdrak ( 2019-08-27 14:56:50 +0000 )edit

@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?

nimdrak gravatar imagenimdrak ( 2019-08-28 01:05:20 +0000 )edit

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 gravatar imageSpooky ( 2019-08-28 02:58:22 +0000 )edit

@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.

nimdrak gravatar imagenimdrak ( 2019-08-28 04:25:40 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2019-08-29 13:17:43 +0000

nimdrak gravatar image

I found an answer.

TSO option ON at NIC card make it difficult to analyze the packets.

After turning off TSP option, I find the common packet loss situation.

But I find that .2 host send a ACK packet slower than usual and .1 host re-transmit the packet.

I don't know why .2 host send a ACK packet slower than usual, yet.

I need to analyze the phenomenon in detail.

Thank you for all!

edit flag offensive delete link more


Like 100ms or 200ms slow? That would be Delayed-ACK being enabled on the receiving side.

From RFC 1122:  When to Send an ACK Segment

    A host that is receiving a stream of TCP data segments can
    increase efficiency in both the Internet and the hosts by
    sending fewer than one ACK (acknowledgment) segment per data
    segment received; this is known as a "delayed ACK" [TCP:5].

    A TCP SHOULD implement a delayed ACK, but an ACK should not
    be excessively delayed; in particular, the delay MUST be
    less than 0.5 seconds, and in a stream of full-sized
    segments there SHOULD be an ACK for at least every second

Do you see an odd number of packets being sent? Then the ACK for the last segment will trigger a delayed ACK. If the retransmission timeout is shorter than the delayed ack timer on the other ...(more)

SYN-bit gravatar imageSYN-bit ( 2019-08-29 21:14:24 +0000 )edit

@SYN-bit Thank you so much! I don't know the concept "delayed ACK". After studying, I will do troubleshooting with it. I appreciate you :)

nimdrak gravatar imagenimdrak ( 2019-08-30 01:45:00 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-08-27 14:12:40 +0000

Seen: 10,768 times

Last updated: Aug 29 '19