If the host your communicating with sends you 4 packets with sequence #'s 10,11,12,13 if you successfully receive all data, the client sends an ACK back with sequence#14 (the next number), if the last two packets were dropped along the way or were corrupted the client would send an ACK back with seq#12 (signaling that it only received 10 & 11) this would then que the host to do a re-transmission of #12,13. Yes it's bad, because tcp is inherently a latency laden protocol. There's multiple causes, mostly network congestion.
Different stages of a TCP connection will have different retransmission strategies and timeouts. For example, during the three-way handshake at the start of the connection, the retransmission characteristics are different than later in the connection.
Are you seeing the retransmission in data coming to you or being sent from you? Is this during the bulk data transfer, or during connection establishment/termination handshake?
For example, during the initial handshake, you may see multiple SYN+ACK packets from the server you are trying to connect to. Some TCP stacks have very aggressive retransmission at that stage. If you see a couple of those, especially if you are talking to a server on the other side of the globe, you have absolutely nothing to worry about. That's still quite normal.
If you are looking at the bulk transfer, and you see retransmission of some of the larger data packets then this indicates a pipeline-stall: The sending side had to stop streaming its data and retransmit. Normally, TCP will try to avoid that and tunes its send and receive windows to that end. Having retransmission occur anyway at that stage probably indicates intermittent packet loss or delay, caused by congestion somewhere along the way.
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
