Vishal,
Pls note my new interim email @.
Sorry for extended delay replying - your mail arrived after I left my
office for the last time (I've left BT).
I'm still "between jobs", but I'm trying to catch up on unfinished
threads - inline.
On 22/05/15 19:01, Vishal Misra wrote:
Bob, Rong
Let me present our rationale for choosing the PI controller (hope it
will be helpful to present the rationale for PIE).
Thank you. Pls put this text in the draft.
In my review I wasn't questioning the use of a PI controller, I was just
pointing out that the draft doesn't include any text that justifies
using PI. Here's what I actually said:
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
4 Articulate the Rationale for a PI Controller
The draft doesn't actually say that a PI controller is chosen to keep
the average latency constant even
under high load. The 3rd para of Intro says that, unlike RED's use of
queue length, PIE uses latency as
the metric. However, that alone could just mean that the latency still
increases with load.
All the rationale in section 4.2 doesn't state this fundamental
reasoning either, except by reference, citing
the original paper on PI [HMTG01].
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
However, since writing that review, we've got results that /do/ question
whether a hard delay threshold is the correct goal (see next email).
When we were working on the issue in 2001-2001, RED had been deployed
everywhere but also disabled everywhere. People had trouble
understanding and tuning RED. Our fluid modeling and control theoretic
analysis showed that RED was a classical Proportional Controller with
a delay element (the queue averaging mechanism. We identified the
following flaws with RED
1. The Proportional control meant that RED could not control the
queue length to a specified value, it is an inherent limitation of
Proportion al control. RED always controlled the queue (and hence
delay) to some value between min_thresh and max_thresh depending on
the load.
2. The delay element (queue averaging) introduced an additional
instability to the control loop making it more difficult to control
(and as Bob has said, the instability is oscillations causing jitter
and loss of some link throughput due to the oscillations).
We decided to redesign the controller but since RED was already
implemented, create a controller that could use the same deployment
with some minor modifications. So what we did to fix the issues was:
1. In classical control theory Integral control drives the steady
state error to zero, so we changed the Proportional Control to
Proportional Integral, or PI control which lets you control the buffer
queue length to a specific, target value independent of the load.
2. We simply removed the queue averaging mechanism.
For the record (I know you know this), it's not as simple as just
removing averaging, because one doesn't want to introduce loss until
it's likely that there's persistent load not just a transient burst. PIE
introduces different smoothing delays (with magnitude based on stability
theory).
The resultant controller could work with existing RED implementations
with a slight modification to the update equation.
The implementation of PIE is much more complex than RED. I assume you
mean you could build PIE on top of the parts of RED implemented in
hardware (but this statement might not be true for all vendors'
implementations).
Bob
-Vishal
--
http://www.cs.columbia.edu/~misra/ <http://www.cs.columbia.edu/%7Emisra/>
On May 22, 2015, at 9:38 AM, Bob Briscoe <[email protected]
<mailto:[email protected]>> wrote:
I didn't mean that you need to justify b etter why you chose a PI
controller. I said you need to "Articulate the Rationale for a PI
Controller"
_______________________________________________ aqm mailing list
[email protected] https://www.ietf.org/mailman/listinfo/aqm
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
