- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 11 Aug 95 11:39:53 MDT
- To: Rich Salz <rsalz@osf.org>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I'd like to know why congestion control can only be done on a TCP-connection basis and not a host-basis? Seems to me you just need a few new ICMP pdu's. The debate about congestion avoidance and control makes the arguments on this mailing list look tame. There's quite a lot of literature on the topic, which I won't attempt to summarize. But I will point out that the reason why congestion avoidance and control is done *today* on a TCP-connection basis is because it's really the only thing that actually works. There is, in fact, an ICMP message type ("Source Quench"). But the consensus seems to be that this is not a good idea. To quote from RFC1716: Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion. See, for example, [INTERNET:9] and [INTERNET:10]. Section [5.3.6] discusses the current thinking on how routers ought to deal with overload and network congestion. INTERNET:9. A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Wilder, and R. Zahavi, Evaluation of Internet Performance - FY89, Technical Report MTR-89W00216, MITRE Corporation, February, 1990. INTERNET:10. G. Finn, A Connectionless Congestion Control Algorithm, Computer Communications Review, vol. 19, no. 5, Association for Computing Machinery, October 1989. As to doing congestion control on a "host basis": this can't work. In general, it's not hosts that get congested (flow control solves that), it's *paths* that get congested. And congestion is a highly dynamic condition; it can occur or clear up on short time scales. Some implementations apparently cache "hints" about the path to peer hosts between TCP connections, but this does not relieve the TCP implementation from the responsibility to detect and avoid congestion at any time. -Jeff
Received on Friday, 11 August 1995 12:42:00 UTC