[e2e] Can feedback be generated more fast in ECN?

[David P. Reed]

At 06:43 PM 2/14/01 -0500, Vijay Gill wrote:
>On Wed, 14 Feb 2001, David P. Reed wrote:
>
>
> > You don't want to operate a network in a highly congested mode.  Router
> > congestion should be rare, or your provisioning, your "admission control"
> > (including such trivial things as restricting edge port capacities to
> > reduce overcommitment of backbone capacity), or your closed-loop flow
> > controls are not doing their job.
>
>Restricting edge port capacities do not necessarily imply that there will
>never be congestion in the core. See Mike O'Dells excellent email
>(archived at: http://www.interesting-people.org/200011/0058.html) for more
>details on this.
>
>We've seen in some fairly large networks that in general, the physical
>topology tends to lag the where the traffic wants to go by some number of
>months to some weeks. This could of course be an result of a very short
>planning horizion coupled with very long provisioning times, but thats
>what the reality happens to be.

I'm usually pretty precise in my language. Confusing terms can lead to  bad 
design - it's like trying to prove theorems based on inconsistent axioms.

Congestion is the condition of a network that is operating with queues near 
full on some paths.  Excessive demand is the condition you are referring to 
that arises when provisioning can't keep up with demand growth, and it is 
not identical to congestion (Excessive demand may, but need not, result in 
congestion).  I think it is terribly clear (and almost trivially obvious) 
that you don't want to operate a network in a congested mode, even when 
demand outstrips supply, because all users will be better off if you reduce 
the amount of traffic entering the net to a level where queues are less 
full.  ECN can help make this happen, as can SQ, but if most packets are 
marked, ECN has already failed to do its job.  Similarly, if all packets 
get SQ'ed, SQ has already failed to do its job.   What digs the network out 
of that worst-case condition is TCP's use of  the "messageless signalling" 
- the *absence* of expected acks and window advancement - as a signal to 
the sender to slow down - which has nothing to do with either ECN or 
SQ.  We might call that "congestion failure recovery" - and it has little 
to do with "normal congestion avoidance" that is accomplished by TCP flow 
control, ECN, and/or SQ.

This observation that operating a network in congestion is bad is no 
different than the observation that running highways with traffic jams 
benefits none of its users.  (Though if you charge a toll per car, it is a 
revenue maximizing strategy for the toll-road operator.  Hence it may well 
be a revenue maximizing strategy for a monopoly Internet provider).


- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html