Bob, Wow, really detailed review. Thank you so much for looking into all the details. We will definitely read them thoroughly and address them properly and revise the draft. This might take some time, please be patient :-).
Thanks, Rong From: Bob Briscoe <[email protected]<mailto:[email protected]>> Date: Friday, May 8, 2015 3:08 AM To: Richard Scheffenegger <[email protected]<mailto:[email protected]>>, "Eddy Wesley M. [VZ]" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: AQM IETF list <[email protected]<mailto:[email protected]>> Subject: [aqm] draft-ietf-aqm-pie-01: review 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
