[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