[e2e] [Fwd: RED-->ECN]

[Alhussein Abouzeid]

The I in the PI controller is "Integrator", which is some sort of
averaging. Just like the averaging of the queue size, a PI controller does
introduce delay in the feedback (another pole as Saverio said), and it is
some sort of averaging, right?
You can on the other hand add a D controller (a zero). In all cases,
you will end up optimizing responsiveness and unstability (KD) versus
sluggishness and stability (I).

The virtue of solving the problem using classical control approach is its
simplicity, accuracy and insights, allowing one to bring in a well known
set of control-theoretic tools to solve the problem, as you did in your
Infocom papers, rather than using ad-hoc attempts to adjust the controller
parameters.

-Alhussein.

 On Sat, 3 Feb 2001, C.V. Hollot wrote:

> At 03:09 PM 2/2/01 -0800, Steven Low wrote:
> >
> >> i used to think that measuring average queue size was really just a
> proxy for
> >> measuring average arrival rate.
> >> 
> >> however, V. Jacobson, K. Nichols, and K. Poduri have pointed out that the
> >> arrival rate might equal the link bandwidth (their example uses TCP ACK
> >> clocking, so no new packets show up until old ones leave), but there may
> still
> >> be a standing queue.
> >> 
> >> thus, if i had been measuring arrival rate, i would have decided "no
> need to
> >> drop [mark] packets".  whereas, i should have been measuring (and seeing) a
> >> standing queue and decided "i need to drop [mark] packets".
> >> 
> >> cheers,  Greg Minshall
> >
> >Indeed.  When input rate equals the output rate in equilibrium, any
> >(equilibrium)
> >queue length is compatible, because 
> >	rate of change of queue = input rate - output rate = 0
> >This means one can attmpt to match input to output rate, and achieve, in
> >equilibrium,
> >full utilizaiton when the queue length stabilizes.   The value at which
> >the queue
> >stabilizes depends on the *process*, i.e., depends on
> >how we do congestion control (TCP/AQM), especially AQM.
> >
> >In REM, the congestion measure (a number we call 'price') is incremented
> >when
> >the weighted sum of rate mismatch (input rate - output rate) and queue
> >mismatch (current queue - target queue, target may be 0) is positive,
> >and
> >decremented otherwise.  When the weighted sum is postive, it means
> >either input
> >rate exceeds output rate, or there is a large queue to be cleared, or
> >both.
> >So REM is striving to drive this weighted sum of mismatches to zero, and
> >it can 
> >be zero (in equilibrium) *if and only if* the both mismatches are zero,
> >i.e.
> >	input rate = output rate and queue = target.    
> >This is how REM achieves high utilization and low queue in equilibrium.
> >
> >Steven
> >
> 
> another point about measuring (and using) average queue size to mark packets:
> average queue size does contain (perhaps useful) information about
> instantaneous queue length and arrival rate.  The real question is how to
> act on this information.  If we use this averaged info to mark packets,
> then we are (implicilty) closing a feedback loop around "stale (averaged)"
> information.
> Queue averaging introduces additional time (phase) delay to the feedback
> (in addition to queuing and propagation delays)- and we know that delayed
> feedback contributes to poor and even unstable feedback behavior. 
> For example, consider the task of controlling the level of water in your
> bath tub if you could only measure the "average level of water." 
> 
> In my opinion it is better to measure instantaneous queue length, and then,
> with a dynamic model of TCP/AQM in hand,  develop AQM algorithms (based on
> instantaneous queue length) to achieve  network performance objectives.
> for more details on TCP/AQM modelling and PI control see
> http://www-net.cs.umass.edu/~misra/ 
> 
> 
> cvh
> --------------------------------------------------
> 
> C.V. Hollot
> Associate Professor
> ECE Department
> University of Massachusetts
> Amherst, MA 01003
> ph:  413.545.1586
> fax: 413.545.1993
>