TCP Reliability and Flow Control
Transmission Control Protocol accepts data from a stream, divides it into small chunks, and adds a TCP header creating a TCP segment. The TCP segment is encapsulated into an Internet Protocol datagram (IP datagram) and exchanged with peers. The TCP Reliability and TCP Flow Control are important for ensuring data received completely and also in the correct order.
TCP Reliability
The TCP segments possibly will arrive at their destination out-of-order. For understanding, the original message to the receiver, the data in these out-of-order segments is reassembled to the correct order. Each segments header has assigned a sequence number to get this goal. The sequence number represents the first data byte of the TCP segment.
During the established session, the first sequence number (ISN); is set. This ISN represents the opening value of the bytes for this session which is transmitting to the receiving side application. When data is transmitting during the established session. The sequence number is increasing by the number of transmitted bytes. This data byte tracking enables every segment to individually find and acknowledged.
The missing segments can identify and also reported. The ISN is effectively a random number. This is to avoid certain types of malicious attacks. For simplicity, we will use an ISN of 1 for the examples. sequence numbers also show how to reassemble and reorder received segments, as shown in the figure.
The receiving TCP process places the data from a segment into a receiving buffer. Segments are in the proper sequence order and passed to the application layer when reassembled. The wrong order sequence number remains hold for later processing. if, when the segments with the missing bytes reach the destination, these segments are processed in proper order.
TCP Flow Control
TCP also 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 flow control makes sure the packets are delivered correctly to the receiver node. The TCP flow control is the service of TC.
Window Size and Acknowledgment
TCP flow control also checks the quantity of data that the destination host can receive and process reliably. It is is the service that 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 acknowledgements which is the process of flow control. 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, the host-B’s initial window size for the TCP session is 1,500 bytes.
Starting with the first byte, byte number 1; the final byte host-A can send without receiving acknowledgements is byte 1,500. This is host-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, that 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 acknowledgement 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 acknowledgement. When the destination bytes are received and processed; the destination host will send acknowledgements to inform the source host that it can continue to send additional bytes.
Usually, the server will wait until receiving all 4,500 bytes before sending an acknowledgement. This means the host can correct its send window as it receives acknowledgements from the server. As shown in the figure when host-A receives an acknowledgement with the acknowledgement number 3,001, it sends window will increment another 4,500 bytes (the size of the 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 acknowledgements 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 acknowledgement. The window size determines the number of bytes that can be sent before expecting an acknowledgement. The next expected byte is calling an acknowledgement number.
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 the packet to acknowledgement. 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 of 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 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 acknowledgement or the acknowledgement not receive timely. Then it can reduce the number of bytes it sends before receiving an acknowledgement. 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 acknowledgement number is for the next; expected byte, not for the segment.