TCP transmission, retransmission and working principle

2023.10.19

TCP transmission, retransmission and working principle


TCP has a fast retransmit feature - retransmits lost segments before the timer expires, to allow fast retransmits we need to set some rules for the sender and receiver.

The IP and MAC layers have limited memory for sending packets. Therefore, they all limit the length of the message.

This restriction requires TCP to pack variable-length bytes into multiple segments before providing them to the IP layer. The length of each segment should be appropriate.

Below is a simple diagram showing how segments are sent over the Internet.

1*IRdfZ4LKKpQ-KRz_Y3QR7g.png

The client's HTTP layer is sending an 18-byte stream to the target server.

While bytes 16-18 have not yet reached the TCP layer, bytes 12-15 pass through it. TCP packages them into a segment and appends a TCP header, marked in the yellow area.

Next, the segment is encapsulated by the IP layer, sent over the Internet, and then reaches the server.

Assume that the TCP segment length exceeds the length supported by the underlying layer. In this case, the IP layer will be responsible for splitting the large segment into multiple fragments. This is an expensive process, so we want to avoid this.

But how does TCP determine the length? This depends on the maximum segment size (MSS).

Ideally, we would like to choose an MSS that maximizes data volume, minimizes header proportions, and avoids further splitting at the IP layer.

By default, the MSS is 536 bytes. Where does this number come from?

  • The default maximum transmission unit (MTU) for IP is 576 bytes. Anything larger than this size will be split.
  • The IP header occupies 20 bytes.
  • The TCP header occupies 20 bytes.

Therefore, 536 = 576 - 20 - 20.

You can see that MSS only represents the size of the data body, excluding the header.

1*creWLybyfKDBJgTzQP1kDg.png

The MSS is negotiated during the TCP three-way handshake. The following is the format of the TCP segment header. MSS is located in TCP options.

1*pQpFRUuyzaG4JOm93Wg5Zw.png

In the SYN message, the client proposes an MSS of 1460 bytes. This is called the sender maximum segment size (SMSS).

1*dG1cCAjKY0v8Xfx2SeBcFA.png

In the server's response, it recommends that the segment size be no more than 1400 bytes. Since the size comes from the server, it is called the Receiver Maximum Segment Size (RMSS).

TCP retransmission

In order to ensure the reliability of transmission, TCP needs to complete two functions:

  • When a message is received, the receiver sends an acknowledgment (ACK) to the sender.
  • When a message is lost, the sender retransmits the message.

Let's start with a simple model.

1*bvkdWnFF55OCLfstaE_GEw.png

1. First, the sender maintains a timer after sending the message. 2. Receive the first ACK before the time expires. The timer is then reset to wait for the second message and the process repeats. 3. The second timer expires and no ACK is received. Retransmission begins.

This simple design is straightforward, but less efficient because each message needs to wait for the previous ACK to return.

Let's improve it.

1*suv0nuvpmgUWaTd6riMUsQ.png

By assigning an ID to each message, we can send multiple messages quickly. The same ID is linked with the corresponding timer and ACK message.

If a message is lost, like #3, the sender will retransmit it.

In TCP, what is a "message ID"? It's the serial number.

1*EbU2NjtCGn8z4gVCJr2Tyg.png

Here is an example message:

  • The length of this TCP segment is 647 bytes.
  • Prior to this message, the sender has sent 1461 bytes.
  • The sender will send more bytes starting at 2108.

Serial numbers can be up to 2³². Then it will start again.

This brings up a problem.

1*RLp9kmWuRzlgY-NQs2F4Hw.png

Imagine we only have 4 sequence numbers and send 1 byte each time.

  • In the process, the 2nd byte (marked #2) is lost. By design, #2 will be retransmitted at a later time.
  • We keep sending more bytes until the sequence number starts at #1. At this time, retransmission #2 is sent.
  • The receiver doesn't know if this is old #2 or new #2. This might mess things up.

To solve this problem, timestamps were introduced in TCP options.

1*jSrwaU0L-2EHyyIxzb2w_A.png

Timestamps disambiguate segments with the same sequence number.

Let's attach a timestamp to each segment.

The receiver reads timestamp B and compares it with the previous timestamp E to confirm that this is a retransmission. Otherwise, the timestamp should be greater than E.

TCP fast retransmit

TCP has a fast retransmit feature - retransmits a lost segment before a timer expires.

To allow fast retransmissions, we need to set some rules for the sender and receiver.

  • Rule 1: As a receiver, it should always send the sequence number it expects to receive. For example, when the receiver receives segment 1, it will respond with ACK2, indicating that it expects to receive segment 2 in the upcoming message.
  • Rule 2: As the sender, it should ignore the timer and start retransmitting the lost segments as soon as it receives 3 duplicate out-of-order ACKs.

1*nbAE5D9yMkUxvxxR4PJ27g.png

The image above shows an example of fast retransmission:

  • After the transmission of the first 2 segments, segment 3 is lost.
  • On receiving segment 4, the receiver sends ACK3 instead of ACK4 according to the rules. This is the first duplicate out-of-order ACK.
  • Again, upon receiving segment 5, the server still expects segment 3 to be retransmitted. Therefore, a second duplicate ACK3 is sent.
  • Then, the third duplicate ACK3 is sent.
  • At this moment, the sender enters fast retransmit and retransmits segment 3. 6. After receiving the missing segment, the receiver's ACK is returned in sequence and expects to receive segment 7 in the upcoming message.
  • But there's a problem - the sender doesn't know if segments 5 and 6 arrived safely until fast retransmission is complete. If both segments are lost, subsequent retransmissions will take longer.

The receiver can share information with the sender through the Selective Acknowledgment (SACK) function in order to facilitate the retransmission process.

TCP selective acknowledgment

1*GhT0tOhF3YGrgQOIY56Esw.png

SACK is located in TCP options.

In SACK, we can specify the range of data that has been received, beyond the acknowledgment number.

1*LujjJhnNyITz1dyL-CFfbA.png

This is an example of a SACK indicating that the received data ranges from 2872 to 3393.

With it, the sender knows that no bytes between these boundaries need to be retransmitted.

Additionally, the sender can identify other lost segments and retransmit them as quickly as possible.

Summarize

  • Maximum Segment Size (MSS) defines the length of a TCP segment.
  • Timers help TCP retransmit lost segments.
  • After receiving 3 duplicate ACKs, fast retransmission starts before the timer expires.
  • Selective acknowledgment (SACK) provides information about received out-of-order bytes to facilitate a fast retransmission process.