- 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