58

The Wikipedia article on TCP indicates that the IP packets transporting TCP segments can sometimes go lost, and that TCP "requests retransmission of lost data".

What exactly are the rules for requesting retransmission of lost data? At what time frequency are the retransmission requests performed? Is there an upper bound on the number? Is there functionality for the client to indicate to the server to forget about the whole TCP segment for which part went missing when the IP packet went missing?

Anirudh Ramanathan
  • 46,179
  • 22
  • 132
  • 191
Randomblue
  • 112,777
  • 145
  • 353
  • 547
  • usually the retransmission time = round trip time * some constant, and a fixed delay (which is quite pessimistic) for the `syn` packet. – John Dvorak Oct 18 '12 at 14:17

2 Answers2

58

What exactly are the rules for requesting retransmission of lost data?

The receiver does not request the retransmission. The sender waits for an ACK for the byte-range sent to the client and when not received, resends the packets, after a particular interval. This is ARQ (Automatic Repeat reQuest). There are several ways in which this is implemented. 

Stop-and-wait ARQ
Go-Back-N ARQ
Selective Repeat ARQ

are detailed in the RFC 3366.

At what time frequency are the retransmission requests performed?

The retransmissions-times and the number of attempts isn't enforced by the standard. It is implemented differently by different operating systems, but the methodology is fixed. (One of the ways to fingerprint OSs perhaps?)

The timeouts are measured in terms of the RTT (Round Trip Time) times. But this isn't needed very often due to Fast-retransmit which kicks in when 3 Duplicate ACKs are received.

Is there an upper bound on the number?

Yes there is. After a certain number of retries, the host is considered to be "down" and the sender gives up and tears down the TCP connection.

Is there functionality for the client to indicate to the server to forget about the whole TCP segment for which part went missing when the IP packet went missing?

The whole point is reliable communication. If you wanted the client to forget about some part, you wouldn't be using TCP in the first place. (UDP perhaps?)

Anirudh Ramanathan
  • 46,179
  • 22
  • 132
  • 191
16

There's no fixed time for retransmission. Simple implementations estimate the RTT (round-trip-time) and if no ACK to send data has been received in 2x that time then they re-send.

They then double the wait-time and re-send once more if again there is no reply. Rinse. Repeat.

More sophisticated systems make better estimates of how long it should take for the ACK as well as guesses about exactly which data has been lost.

The bottom-line is that there is no hard-and-fast rule about exactly when to retransmit. It's up to the implementation. All retransmissions are triggered solely by the sender based on lack of response from the receiver.

TCP never drops data so no, there is no way to indicate a server should forget about some segment.

Brian White
  • 8,332
  • 2
  • 43
  • 67
  • "guesses about exactly which data has been lost" SACK (selective acknowledge) is not guessing. I hope you don't mean SACK. – John Dvorak Oct 18 '12 at 14:21
  • The receiver may re-ACK previous data when an out-of-order segment has been received. This hints to the sender that some but not all of the pending packets have been lost and so the sender may choose to retransmit only a subset of what is in its outgoing window (and thus result in a smaller network packet and less overall bandwidth use) rather than sending a bigger packet that includes data previously sent in a later packet (which would otherwise reduce latency and the number of packets sent in the case of multiple losses). There is no certainty, so let's call it an "educated guess". – Brian White Oct 18 '12 at 14:32
  • 1
    see SACK. It is an additional header that tells the sender exactly what the receiver has. I believe nearly all contemporary TCP stacks implement SACK nowadays – John Dvorak Oct 18 '12 at 14:35
  • Yeah, there are a lot of TCP extensions to help. Most of my work has been on bare-bones implementations (no extensions at all) on tiny embedded systems. – Brian White Oct 18 '12 at 15:14
  • "TCP never drops data" What about a server being offline during retransmission requests and coming back online after the client times out – TZubiri Aug 05 '20 at 06:45
  • If the connection is "broken" then it's broken. In that case, the end of the stream as seen by the client could be anywhere. But as long as the connection is "established", no data is dropped. See https://stackoverflow.com/questions/13085676/tcp-socket-no-connection-timeout/13087392#13087392 – Brian White Sep 02 '20 at 20:12
  • Is there something to attempt fragmentation by sending smaller packets if there is Path MTU Discovery black hole in the way and say there is incorrect MSS clamping done? So like small packets go through but not the ones large enough. – mlt Mar 26 '23 at 17:11
  • I have seen older switches (Redback) that would drop packets larger than they could handle instead of fragmenting them as they're supposed to. In that case, all bets are off. The receiver will never `ack` so the sender will retry and the retries will also get dropped. This continues until the connection times out. That's a plain broken implementation. PathMTU is an optimization to avoid fragmentation, not part of the base TCP spec. – Brian White Mar 27 '23 at 00:31