[aqm] Questioning each PIE heuristic

[Bob Briscoe <[e-mail]>]

Rong, Preethi, Greg, Fred, and others involved in PIE,

You may recall that when we wrote PI2 we didn't include any of PIE's 
heuristics. Mostly because PI2 solved the issues they addressed 
intrinsically. But we left some until we had checked their benefit, 
which is what I'm doing now...

My first question is about this heuristic in PIE:

          //Safeguard PIE to be work conserving
          if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2)
                || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) {
               return ENQUE;
          }

If it tests true, this block doesn't stop the calculation of drop_prob_ 
evolving, but it disables it being able to lead to any random packet drop.

I can understand why you want to disable packet drop when the queue is 
no more than 2 packets.
My question is about the first half of the logical OR. The drop_prob_ < 
20% test will be true under normal non-overloaded conditions. So I have 
just realized that the qdelay_old_ < QDELAY_REF/2 test will turn off 
random drop very often. I would expect this to radically impact the 
behaviour of PIE. It seems to be overriding the PI controller as if you 
are thinking "actually we don't really trust the PI controller to leave 
it to do its thing, so we've overridden it a lot of the time." For 
instance, whenever a single long-running TCP flow with RTT about the 
same as the target delay is saw-toothing, this test will disable random 
drop completely during the lower half of every saw-tooth in the queue. 
Maybe that's OK, but...

Without this test, the PI controller should reduce drop probability as 
the queue sawtooths down anyway. If another flow causes the queue to 
rise rapidly while it is under half the target, the PI controller is 
designed to detect such an increase and translate it into drop. But this 
heuristic suppresses any drop until the queue has exceeded half the target.

So my questions are:

Q1. What were the reasons for introducing such a frequent suppression of 
the PI algorithm (the RFC just says what this code does, not why)?

Q2. Why use qdelay_old_ in the test? This seems to drive suppression of 
drop using stale state.

Q3. Having said that it looks like this heuristic will significantly 
alter PIE's behaviour, in tests under a very wide range of traffic 
conditions, link rates, mixed RTTs, traffic models etc, we have found 
that removing the heuristics makes no measurable difference to PIE's 
performance. So if you added this heuristic for a specific scenario, 
please describe it, so we can test for it.


Cheers


Bob




-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/