Introduction to TCP timeout retransmission, sequence number, sliding window

12 TCP: Transmission Control Protocol (Preliminary)

12.1 Introduction

Many protocols on Ethernet do not contain reliable transmission mechanisms themselves. They may use a mathematical function such as checksum or CRC to detect whether the received data contains errors, but they will not try to correct the errors. Especially for the IP protocol and UDP protocol, the error correction function is not implemented at all . Although some upper layer protocols based on the IP protocol or UDP protocol will provide a certain number of retransmission mechanisms, they will still give up retransmission if they are not successful.

The communication medium may lose or change the information transmitted. There are currently two main methods to try to avoid errors in the transmission of information:

• Error check code: (Basically add some honor bits, so that even if some bits are modified, the real information can be recovered), using error correction codes to correct communication problems is a very important addition to errors method.

• ARQ: (Automatic Repeat Request), this method is referred to as automatic repeat request, which forms the basis of many protocols, including the TCP protocol.

12.1.1 ARQ and retransmission

Several problems often encountered when discussing IP data packets: packet reordering, packet replication, and packet loss. 一个直接处理分组丢失的方法是重新发送分组知道它被正确的接收。This requires a method to judge:

1) Is the receiver grouped?

2) Is the packet received by the receiver exactly the same as the data sent by the sender?

To determine that they have received a packet is received, this method is called by sending a signal to the sender acknowledgment (acknowledagment) or the ACK .

The most basic form should be:

i. The sender sends a packet and then waits for an ACK.

ii. After receiving this packet, it should send the corresponding ACK;

iii. When the sender receives this ACK, he sends another packet. Repeat this process afterwards

But there are additional problems introduced here:

(1) How long should the sender wait for an ACK for a packet?

(2) What if the ACK message is lost?

(3) What if the packet is received but it contains an error message?

the answer is:

(1) The first question is more esoteric. Deciding how long to wait depends on how long it takes to wait for an ack to be sent.后续讨论

(2) The second question is easier: just that 如果一个ACK丢失了，发送方不能轻易的将这种情况与原分组丢失的情况区分开，因此它简单的再次发送原分组. In this case, the receiver may receive multiple duplicate copies , so the receiver must deal with this situation.

(3) The third question: We use the form of checksum to detect whether the packet contains errors. If it contains errors, we will not reply to the corresponding ACK message, so the sender will resend the packet.

So far, even the simplest application scenario will encounter a problem: the receiver may receive multiple duplicate copies .

Solving this problem requires the use of sequence numbers . The receiver determines whether the current message has been received by the sequence number in the message packet. If it is, the packet is discarded.

Although the protocol introduced so far is reliable, it has low efficiency and low throughput. Because every time a packet is sent, "stop and wait" is required. For a network that will not damage or lose too many packets, the reason for the low throughput is that the network is often in a leisure state- if we allow multiple packets to enter the network at the same time, we can make it "busier", thereby improving Network throughput.

Obviously, allowing multiple packets to enter the network at the same time will make things more complicated:

• sender

(1) We must decide not only when to inject packets into the network, but also how many packets to inject;

(2) And must indicate how to maintain the timer when waiting for ACK;

(3) At the same time, a copy of each unacknowledged packet needs to be saved to prevent retransmission.

• receiver

(1) The receiver needs a more complicated ACK confirmation mechanism: it can distinguish which packets have been received and which have not been received;

(2) In addition, the receiver needs a more complicated caching mechanism: allowing maintenance of "out-of-order" packets

• other

(1) What should I do if the rates of the receiver and the sender do not match? For example, fast sending and slow receiving rate.

12.1.2 Grouped windows and sliding windows

In order to solve all these problems, we assume that each group starts with a sequence number. We define a packet window (window) has been transmitted as a collection packet sender but confirmation has not been completed, we have the number of packets in the window is referred to as the window size (window size).

The above figure shows the current three grouped windows, the size of the entire window is 3.

1) Packet No. 3 has been sent and the other party's ACK confirmation message has been received, so the copy saved by the sender can be released.

2) Group 7 is ready, but has not yet been sent. Because it has not entered the "window".

Now we imagine that the data flows from the sender to the receiver, and the ACK flows in the opposite direction. The sender may receive the ACK message of packet 4 next. When this happens, the window slides a packet to the right, a copy of packet 4 can be released, and packet 7 can be sent. This sliding of windows adds a name to this type of protocol: the "sliding window" protocol

Using the "sliding window" method can deal with many of the problems expressed so far. Generally speaking, this window structure will exist on both the sender and receiver:

• sender

  Record which packets can be released, which packets have been sent and waiting for confirmation, and which packets cannot be sent.

• receiver

  Record which packets have been received and confirmed, which packets are expected next (including how much memory has been allocated to save them), and which packets will be discarded even if they are accepted.

Although the window structure makes it easy to record the data flowing between the sender and the receiver, it does not provide a method for how big the window should be or what happens when the receiver cannot process the data that was sent .

12.1.3 Variable window: flow control and congestion control

As shown in the figure above, when the rate of the three is q> m> n, the bottleneck of the network is the receiver . The problem arises when the receiver processes the issuance too slowly relative to the sender. Our common method is to force the sender to slow down. This is called flow control . There are two common flow control methods:

• Speed -based

  He assigns a certain rate to the sender, while ensuring that the data sent will never exceed this rate. This type of flow control is more suitable for applications and can be used for multicast or broadcast discovery.

• Window -based

  It is based on the sliding window method, in this case, the window size is variable with time. Recipient notification message to the sender window size becomes window advertisement (window advertisement) or a window update (window update). Logically, although the window update and the ACK message are separate, it 实际上窗口更新和ACK经常由同一个分组携带means发送方往往会在它的窗口滑动到右边时同时调整它的窗口的大小 .

---

As shown in the figure above, when the rate of the three is m> n> q, the bottleneck of the network lies in the middle network equipment . At this time, if the sender and the receiver use more than the maximum rate that the intermediate network device can handle, it will also cause data loss. This situation is called congestion control . Congestion control mainly refers to when the rate of the sender is greater than the rate of a certain router device in the middle, we need to take measures to not overwhelm the network between it and the receiver.

12.1.4 Variable window: set retransmission timeout

This value is uncertain and is a statistical result based on a large amount of data.

Collated from "TCPIP Detailed Explanation Volume 1"