[e2e] Can feedback be generated more fast in ECN?
David P. Reed
dpreed at reed.com
Wed Feb 14 06:49:56 PST 2001
At 09:07 AM 2/14/01 +0800, Zhang Miao wrote:
> >In short, I guess ECN is trying to be consistent with the traditional
> >Internet model -- keep the core simple and let the edge do the smart work.
> >
>
>I agree. This is a general rule.
There's a reason for this - it's more than a rule. IP carries many
protocols other than TCP (and one can even argue that there are several
different "species" of TCP, if you couple in application behavior
differences, such as FTP vs. Telnet vs. HTTP).
The proper adaptive response to congestion MUST coordinate the requirements
of both transmitter, receiver, and application layer. The transport
network cannot presume that "quenching the source" is the best
response. The assumption that shortening the latency before "quenching",
and discarding packets is optimal presumes a particular congestion-control
policy that makes sense only with long-hold-time, stable-rate flows. More
generally, applications have a lot of other things they can do to respond
to congestion (rerouting, app level compression and prioritization, ...).
The real problem with SQ is that its name implies a semantics that is not
general. If the message were instead called "early source congestion
notification" (the ICMP ESCN message), which was triggered only for IP
packets that had a flag requesting such notification, and reflected through
the IP layer to an application layer for handling, it would clearly be more
general than ECN (it would handle multicast UDP traffic at least as well or
better). Eric Hall is right that the arguments against SQ are pretty weak
or irrelevant. There are some good arguments against focusing all one's
congestion control effort on a router-based, path-based scheme, but they
are arguments against ECN as well.
But the big elephant here is that looking at the packet level in a local
router will never be the right place or time to solve congestion. At best
it is a way to help the network 's users cooperate to survive unforseeable
transients that should be prevented earlier.
- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html
More information about the end2end-interest
mailing list