TCP is the protocol that guarantees a reliable communication channel over an unreliable network. When someone sending data to another host, the host can receive the packets out of order; the host can lose the packets or 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 PC A’s sending window. The window size is also 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 calling 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 of receiving all the bytes at the destination host, can it continue sending more data for the session. Usually, the destination host will not wait for all receiving all bytes for its window size before replying with an acknowledgment. When the destination bytes 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 wait until receiving all 4,500 bytes 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 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 next expected byte is calling an acknowledgment number.

TCP Flow Control – Congestion Avoidance

When congestion occurs on a network, it results in packets discarding due to overload on the router. When packets containing TCP segments don’t reach their destination, they leave packet to unacknowledge. By determining the rate at which TCP segments sending but not acknowledging; 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 does not control properly the extra retransmission of the TCP segments can make the congestion even worse. Not only are new packets with TCP segments introduce into the network; but the feedback effect of the retransmits TCP segments which 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 did not receive an acknowledgment or the acknowledgment not receive 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 above illustrates the TCP congestion control. The acknowledgment number is for next; expected byte not for the segment.