> 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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to