TCP is the protocol that guarantees a reliable communication channel over an unreliable network. When someone sends data from a host to another, packets can be lost, they can arrive at the receiving host out of order, the network can be congested or the receiver node can be overloaded. When we are sending some application data, we usually don’t need to deal with this complexity, we just write data to a socket and TCP makes sure the packets are delivered correctly to the receiver node. The TCP provides important service which is called TCP Flow Control.
The quantity of data that the destination host can receive and process reliably. TCP flow control is the service which maintains the reliability of TCP transmission by adjusting the rate of data flow between the source host and destination host for an established session. To achieve this, the TCP header includes a 16-bit field called the window size.
The figure below illustrates an example of window size and its acknowledgments. The window size is the number of bytes that the destination device of a TCP session can accept and process a single time. In this example, host B’s initial window size for the TCP session is 1,000 bytes. Starting with the first byte, byte number 1; the final byte PC A can send without receiving acknowledgments is byte 1,000. This is known as PC A’s send window. The window size is included in every TCP segment so the receiver can adjust the window size at any time depending on buffer availability.
The figure illustrates, the source is transmitting 1,500 bytes of data within each TCP segment. This is known as the MSS (Maximum Segment Size).
The primary window size is settled upon when the TCP session is established during the three-way handshake. The source host must bound the number of bytes sent to the destination host based on the destination’s window size.
Only after the source host receives an acknowledgment that the all the bytes have been received at the destination host, can it continue sending more data for the session. Usually, the destination host will not wait for all the bytes for its window size to be received before replying with an acknowledgment. As the bytes are received and processed; the destination host will send acknowledgments to inform the source host that it can continue to send additional bytes.
Usually, host B will not wait until all 4,500 bytes have been received before sending an acknowledgment. This means host A can correct its send window as it receives acknowledgments from host B. As shown in the figure below, when host A receives an acknowledgment with the acknowledgment number 3,001, host A’s send window will increment another 4,500 bytes (the size of host B’s current window size) to 7,500. host A can now continue to send up to another 4,500 bytes to host B as long as it does not send past its new send window at 7,500. The process of the destination host sending acknowledgments as it processes bytes received and the continual adjustment of the source’s send window is known as sliding windows.
If the availability of the destination’s buffer space decreases; it may reduce its window size to inform the source to reduce the number of bytes it should send without receiving an acknowledgment. The window size determines the number of bytes that can be sent before expecting an acknowledgment. The acknowledgment number is the number of the next expected byte.
TCP Flow Control - Congestion Avoidance
When congestion occurs on a network, it results in packets being discarded by the overloaded router. When packets containing TCP segments don’t reach their destination, they are left unacknowledged. By determining the rate at which TCP segments are sent but not acknowledged; the source host can suppose a certain level of network congestion.
One of the main principles for congestion control is avoidance. TCP tries to sense symbols of congestion earlier than it happens and to reduce or increase the load into the network accordingly. The option of waiting for congestion and then reacting is not as good as because once a network saturates; it does so at an exponential growth rate and decreases on the whole throughput enormously. It takes a long time for the queues to consume, and then all senders host again repeat this phase. By taking a practical congestion avoidance approach; the pipe is kept as full as possible without the threat of network saturation. The key is for the sender host to recognize the state of the network and client and to control the amount of traffic injected into the system.
Whenever there is congestion, retransmission of lost segments from the source will take place. If the retransmission is not properly controlled, the extra retransmission of the TCP segments can make the congestion even worse. Not only are new packets with TCP segments introduced into the network; but the feedback effect of the retransmitted TCP segments that were lost will also add to the congestion. To avoid and control congestion, TCP employs several congestion management mechanisms, timers, and algorithms.
If the source host determines that the TCP segments are either not being acknowledged or not acknowledged in a timely. Then it can reduce the number of bytes it sends before receiving an acknowledgment. Note that it is the source host that is decreasing the number of unacknowledged bytes it sends and not the window size determined by the destination. The figure below illustrates the TCP congestion control. The acknowledgment number is for next expected byte not for the segment.
