Congestion avoidance and control

The previous paper ("Analysis of Increase/Decrease...") could be thought of as providing a theoretical reason for additive-increase/multiplicative-decrease. This paper seem to be addressing practical implementation issues, describing a number of algorithms for TCP while providing some empirical reasons as to why they make sense. On the whole, I found this paper to be less rigorous, oftentimes hand-waving arguments through, and taking a rather condescending tone towards readers. Note to self: do not ever put your readers in a foul mode through your writing.

The paper assumes that rate-control is achieved with transmit windows (unlike the previous paper which was agnostic to how rate-control was performed). The first algorithm the authors explained was slow-start, which gradually increases the rate to the advertised rate to prevent a sender from overwhelming network resources when starting transmission. This is of course not the same as the AIMD congestion avoidance, so the authors describes how both slow-start and AIMD can be used together, but in the Appendix. Anyway, the key idea is that in multiplicative-decrease, instead of simplying using a congestion window that is halved, slow-start is used to reach the halved congestion window, before switching to the more conservative additive increase mode (if possible).

Another issue that is addressed is estimating RTT, which is necessary for determining when to perform retransmission. Along the way, the authors also mention the use of exponential back-off in retransmission.

Here, the paper mention reliably detecting knee-points as an open problem, and mentions the possibility of using RTT/queue length prediction as one possible method. Another issue is that of coping with misbehaving hosts (whether accidental or intentional). This was mentioned early in the introduction, leading me to hope that it would address the questions I had about the previous paper. However, it was not brought up again until the end of the paper when the authors discussed future work for gateway control, though there did not seem to be any concrete ideas.