How does TCP handle the flow control problem? Explain it
with the help of a diagram showing the status of sliding window at the
different stages.
Ans :
The main task of the Transmission Control Protocol is simple:
packaging and sending data. Of course, almost every protocol packages and sends
data. What distinguishes TCP from these protocols is the sliding window
mechanism that controls the flow of data between devices. This system not only
manages the basic data transfer process, it is also used to ensure that data is
sent reliably, and also to manage the flow of data between devices to ensure
that data is transferred efficiently without either device sending data faster
than the other can receive it.
To enable TCP to provide the features and quality of data transfer that applications require, the protocol had to be enhanced beyond the simplified data transfer mechanism we saw in preceding sections. Extra “smarts” needed to be given to the protocol to handle potential problems, and changes to the basic way that devices send data were implemented to avoid inefficiencies that might otherwise have resulted. In this section I describe how TCP ensures that devices on a TCP connection communicate in a reliable and efficient manner. I begin with an explanation of the basic method by which TCP detects lost segments and retransmits them. I discuss some of the issues associated with TCP's acknowledgment scheme and an optional feature for improving its efficiency. I then describe the system by which TCP adjusts how long it will wait before deciding that a segment is lost. I discuss how the window size can be adjusted to implement flow control, and some of the issues involved in window size management. This includes a look at the infamous “Silly Window Syndrome” problem, and special heuristics for addressing issues related to small window size that modify the basic sliding windows scheme. I conclude with a discussion of TCP's mechanisms for handling and avoiding congestion
TCP uses an end-to-end flow control protocol to
avoid having the sender send data too fast for the TCP receiver to receive and
process it reliably. Having a mechanism for flow control is essential in an
environment where machines of diverse network speeds communicate. For example,
if a PC sends data to a smartphone that is slowly processing received data, the
smartphone must regulate the data flow so as not to be overwhelmed.
TCP uses a sliding window flow control protocol. In
each TCP segment, the receiver specifies in the receive window field
the amount of additionally received data (in bytes) that it is willing to
buffer for the connection. The sending host can send only up to that amount of
data before it must wait for an acknowledgment and window update from the
receiving host.
TCP sequence numbers and receive windows behave very much
like a clock. The receive window shifts each time the receiver receives and
acknowledges a new segment of data. Once it runs out of sequence numbers, the
sequence number loops back to 0.
When a receiver advertises a window size of 0, the sender
stops sending data and starts the persist timer. The persist timer
is used to protect TCP from a deadlocksituation that could arise if a
subsequent window size update from the receiver is lost, and the sender cannot
send more data until receiving a new window size update from the receiver. When
the persist timer expires, the TCP sender attempts recovery by sending a small
packet so that the receiver responds by sending another acknowledgement
containing the new window size.
If a receiver is processing incoming data in small
increments, it may repeatedly advertise a small receive window. This is
referred to as the silly window syndrome, since it is inefficient to send
only a few bytes of data in a TCP segment, given the relatively large overhead
of the TCP header.
Enhancing TCP to
reliably handle loss, minimize errors, manage congestion and go fast in very
high-speed environments are ongoing areas of research and standards
development. As a result, there are a number of TCP congestion avoidance
algorithmvariations.
No comments:
Post a Comment