1-21: TCP timeout and retransmission (timeout and retransmission)

1-21: TCP timeout and retransmission (timeout and retransmission)

I. Introduction
1: similar to the ARQ protocol of the data link layer, TCP uses the retransmission mechanism of timeout retransmission.
That is, a timeout retransmission timer is set for each packet segment sent by TCP.
The timeout retransmission time RTO (retransmission time-out) set by this timer should be slightly greater than the average round-trip delay RTT of the TCP packet segment. Generally, RTO = 2rtt is recommended.
However, you can also manually adjust the RTO value based on the actual situation. For example, you can set the timeout retransmission time RTO = 90 seconds.
When the TCP packet segment has not received the expected validation information after the specified Timeout retransmission time, the TCP packet segment must be re-transmitted.

Ii. Four timers
1: retransmission Timer: When a TCP packet segment is sent, a retransmission timer for this specific packet segment is created. There may be two situations:
A: If a message segment is confirmed before the timer End Time (usually 60 seconds), the timer is revoked.
B: If the timer deadline is reached before receiving confirmation for this specific packet segment, the packet segment will be re-transmitted and the timer will be reset.
2: persist Timer: TCP needs another timer to handle zero-window notifications.
It is assumed that the received TCP has declared that the window size is zero. When TCP is sent, the transmission packet segment is stopped until a non-zero window size is announced. However, this confirmation may be lost.
We know that in TCP, confirmation is not required. If it is confirmed that the packet is lost, the receiving TCP does not know, but will think that it has completed the task, and wait for the TCP to send more packets. However, because TCP does not receive the confirmation, it will wait for the recipient to send the confirmation to notify the window size. Both sides of TCP are always waiting for the other side.
To enable this deadlock, TCP uses a persistence timer for each connection. When sending TCP receives a confirmation that the window size is zero, it starts to stick to the timer. When the timer period is reached, send TCP to send a special packet segment, called the detection packet segment. This packet segment contains only one byte of data. It has a sequence number, but its sequence number never needs to be confirmed. This sequence number is ignored even when the data of other parts is confirmed. Detection message segment reminder peer: Check that the packet has been lost and must be re-transmitted.
Set the timer value to the retransmission time value. However, if you do not receive a response from the receiving end, you need to send another detection packet segment and add and reset the timer value. The sender continues to send the probe packet segment, and adds and resets the value set by the timer until the value is increased to the threshold (usually 60 seconds. After that, the sender sends a detection packet segment every 60 seconds until the window is reopened.
3: keepalive timer (keepalive timer): The timer is used in some implementations to prevent long periods of idle time between two TCP connections.
Assume that the customer opens the connection to the server, transmits some data, and then remains silent. Maybe this customer is faulty. In this case, the connection will always process the open state.
To solve this problem, in most implementations, the server is configured with a life-saving timer. The timer is reset whenever the server receives a message from the customer.
The active timer is usually set to 2 hours. If the server has not received the customer's information after two hours, it will send the detection packet segment.
If 10 detection packet segments (75 seconds each time) have not responded, the connection is terminated if the customer fails.
4: Time wait timer (2msl timer): The time Wait timer is used during connection termination.
When TCP closes a connection, it does not think that the connection is actually closed immediately.
During the wait time period, the connection is still in an intermediate transitional state.
This allows duplicate fin segments (if any) to reach the destination site and discard them.
The value of this timer is usually set to twice the lifetime of a packet segment.

Iii. Terms used in congestion control
Data Segment: a data segment is any TCP/IP data or Validation Package (or both ).
Size of the maximum data segment of the sender (SMSs): SMSs is the size of the maximum data segment that the sender can send. This value is based on the maximum transmission unit (MTU), MTU path discovery algorithm, rmss (see the next item), or other factors. This dimension does not include the TCP/IP header and options.
Maximum data segment size (rmss): rmss is the maximum data segment size that the receiver is willing to receive. This value is described in the MSS option sent by the receiving end when the connection starts. Or, if the MSS option is not used, it is 536 bytes [bra89]. This size does not include the TCP/IP header and option.
Full Data Segment: a data segment that includes the maximum allowed data segment (that is, a data segment that includes SMSs bytes ).
Receiving end window (rwnd): the receiving end window of the latest notification.
Congestion window (cwnd): a tcp status parameter represents the maximum data volume that a TCP can send. In any
At a given time point, TCP does not send data with a sequence number greater than the maximum validation sequence number and smaller data in cwnd and rwnd.
Initial window (IW): the size of the congestion window at the sender end after the three-way handshake is completed.
Loss window (lw): the size of the congestion window after a TCP retransmission timer detects data loss.
Restart window (RW): the restart window is the size of the congestion window after TCP re-starts transmission after a period of idle time (if the slow start algorithm is used; see section 4.1 for more discussions ).
Transfer size: Total amount of data sent but not confirmed.