> On Oct 21, 2015, at 6:22 PM, Alia Atlas <akat...@gmail.com> wrote: > > Alia Atlas has entered the following ballot position for > draft-ietf-aqm-fq-implementation-03: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-implementation/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for a clear and well-written draft. > > I would like to understand the reference of "Weighted Fair Queues" and have > that clarified in the draft. It's a technical concern, but I have confidence > that the authors and ADs will address it. > > 1) Sec 2.2.3 refers to "Weighted Fair Queues" as well as "Calendar Queues". > Perhaps it is due to a lack in my recent background - but what's described is > nothing like Weighted Fair Queuing > (https://en.wikipedia.org/wiki/Weighted_fair_queueing). Do you have a > reference for "Weighted Fair Queues" or something else in mind??
Thanks for your question. The original intent of this draft was simply to support a discussion, which I expected might be closed without needing to publish an RFC. The working group decided that it wanted to adopt and publish the note, which is fine as well. I think what you're looking at is the difference between theory and practice. As you know, in theory, they are the same thing, and in practice there can be important differences. If you read early papers, such as McKenny's SFQ or Lixia Zhang's Virtual Clock, they talk a lot about WRR-based implementations; calendar queues came later. But no real implementation I am aware of (I have written two and am aware of several others) attempts to implement GPS as the GPS paper describes it - nor does the GPS paper expect them to. That's why that section in the draft is titled "Approximations to GPS" - any implementation is necessarily an approximation, and GPS describes the theoretical best case they are trying to approximate.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm