Richard, Wes, (and Rong plus all the PIE authors),
In Dallas you 'volunteered' me to review draft-ietf-aqm-pie-01
First, thanks to the draft authors for developing this, writing it
up, evaluating it and maintaining it.
I read an early draft when it just described the basics and it was
fine. However, now we have the pseudocode and enhancements, I have a
number of concerns...
My full review is here:
<http://www.bobbriscoe.net/projects/latency/piervw_tr.pdf>
My technical points run to 15 pages. I could have turned it into I-D
format, but I chose to use PDF for a tech report format, 'cos the
review includes charts and maths. I've put significant work into this
over the past couple of weeks, particularly preparing charts to
justify my technical points in the body of the review. So I hope it
gets read thoroughly. The review ends with a 7 page tailpiece of
editorial nits, references, etc.
Over the next few days I may break it down, by pasting the important
points into manageable bite-sized emails to the list. But I recommend
the tech report format for a proper read.
==Exec Summary==
The PIE draft ends with two assertions in the Discussion section:
"PIE is simple to implement"
"PIE does not require any user configuration"
I am afraid I have to say that I do not believe either statement is
warranted any more. PIE has lost its way a bit. The implementation
has not retained the elegance of the theory. The performance benefit
from so-called `enhancements' is questionable or non-existent,
whereas the added complexity is very apparent. Also PIE now contains
a large number of hard-coded constants (I counted 20) that ought to
be scenario-dependent configuration variables.
==Main concerns==
This is a table of contents of the technical part of the review:
* Proposed Standard, but no normative language
* work needed to distinguish between design intent and
specific implementation
* unclear how strongly the enhancements are recommended
* Has PIE been separately tested with and without each
enhancement, to justify each?
* Needs to enumerate whether it satisfies each AQM Design Guideline
* If not, say why or fix.
* Particular concerns:
* No spec of ECN behaviour
* No autotuning of the two main parameters
* Transport specific (Reno-based?) autotuning of alpha & beta
* Rationale for a PI controller not properly articulated
* Technical flaws/concerns
* Turning PIE off
* So-called `autotuning' of alpha & beta parameters
* Averaging problems
* Burst allowance unnecessary?
* Needs a Large Delay to Make the Delay Small
* Derandomization: a waste of cycles
* Bound drop probability at 100% --> DoS vulnerability?
* Avoiding Large Packet Lock-Out under Extreme Load.
* Numerous magic numbers
* ~20 constants, 13 of which are not in the header block.
* About half ought to be made to depend on other constants
* Need to state how to set the remaining constants for
different environments
* Implementation suggestion for Autotuning alpha & beta
Bob
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
