In our discussion of TCP congestion control in Section 3.7, we implicitly assumed that the TCP sender always had data to send. Consider now the case that the TCP sender sends a large amount of data and then goes idle (since it has no more data to send) at t 1 . TCP remains idle for a relatively long period of time and then wants to send more data at t 2 . What are the advantages and disadvantages of having TCP use the cwnd and ssthresh values from t 1 when starting to send data at t 2 ? What alternative would you recommend? Why?
An advantage of using the earlier values of cwnd and ssthresh at t2 is that TCP would not have to go through slow start and congestion avoidance to ramp up to the throughput value obtained at t1. A disadvantage of using these values is that they may be no longer accurate. In particular, if the path has become more congested between t1 and t2, the sender will send a large window’s worth of segments into an already (more) congested path.
Advantages of using t1’s CWND & ssthresh |
Disadvantages of using t1’s CWND & ssthresh |
If the network was NOT caught in congestion between t1 and t2 then the user is able to restore the same performance of the network at t1 |
If the network was caught in congestion between t1 and t2, the sender will be presented with two scenarios. Scenario one is to wait for three duplicate ACKs (Reno) and go into Fast Recovery (ssthresh= cwnd/2, cwnd = ssthresh + 3 MSS). Scenario two is to timeout and go into slow-start (ssthresh =cwnd/2, cwnd = 1 MSS). The problem with both of these scenarios is that they are still based on cwnd from t1 which is not consistent with the changes that may have occurred between t1 and t2. |
My solution: is to use Fast Recovery at t2, that is to send three packets and wait for three-duplicate ACKs. When the ACKs are received, proceed by setting ssthresh = cwnd/2 and cwnd = ssthresh + 3 MSS. This solution gurantees average performance regardless of congestion between t1 and t2.
Post the discussion to improve the above solution.