Is it possible for TCP Reno to reach a state with the conges

Is it possible for TCP Reno to reach a state with the congestion window size much larger that (e.g., twice as large as) RTT X bandwidth? Is it likely? (150 word minimum).

Solution

Is it possible for TCP Reno to reach a state with the congestion window size much larger that (e.g., twice as large as) RTT X bandwidth? Is it likely?

Answer :

No,it is not possible for TCP Reno to reach a state with the congestion window size much larger that (e.g., twice as large as) RTT X bandwidth..Work on congestion culminated in 1990 with the flavor of TCP known as TCP Reno. The congestion-management mechanisms of TCP Reno remain the dominant approach on the Internet today, though alternative TCPs are an active area of research and we will consider a few of them.

TCP’s congestion management is window-based; that is, TCP adjusts its window size to adapt to congestion. The window size can be thought of as the number of packets out there in the network; more precisely, it represents the number of packets and ACKs either in transit or enqueued. An alternative approach often used for real-time systems is rate-based congestion management, which runs into an unfortunate difficulty if the sending rate momentarily happens to exceed the available rate.

In the very earliest days of TCP, the window size for a TCP connection came from the AdvertisedWindow value suggested by the receiver, essentially representing how many packet buffers it could allocate. This value is often quite large, to accommodate large bandwidth×delay products, and so is often reduced out of concern for congestion. When winsize is adjusted downwards for this reason, it is generally referred to as the Congestion Window, or cwnd (a variable name first appearing in Berkeley Unix). Strictly speaking, winsize = min(cwnd, AdvertisedWindow).

             The optimum window size for a TCP connection would be bandwidth × RTT_noLoad. With this window size, the sender has exactly filled the transit capacity along the path to its destination, and has used none of the queue capacity.

Actually,TCP Reno does not do this.

Instead,TCP Reno does the following:

1.Guesses at a reasonable initial window size, using a form of polling

2.It Slowly increases the window size if no losses occur, on the theory that maximum available throughput may not yet have been reached.

3.Rapidly decreases the window size otherwise, on the theory that if losses occur then drastic action is needed