Re: [aqm] Alia Atlas' Yes on draft-ietf-aqm-codel-07: (with COMMENT)

Mirja Kühlewind <ietf@kuehlewind.net> Wed, 19 April 2017 17:50 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194EA129B82 for <aqm@ietfa.amsl.com>; Wed, 19 Apr 2017 10:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4C0mIDb2bSa for <aqm@ietfa.amsl.com>; Wed, 19 Apr 2017 10:50:43 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BFD129B83 for <aqm@ietf.org>; Wed, 19 Apr 2017 10:50:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=D1g1o5OVFm4e2qjQpv+IoRrXt/sAjqfK9HCApIHyduBFQjzPGJWDXKIxMhzIFRZuKqj4cAyuuZQwJYNIonTADHShpbS0UlLK7nlZuUZNCvgcROUEAbyIgoi0Vwgw3rPV1eboCwrlFmQ5R29ncjbsnl9rcP/PDbhFknvDCr0fnRk=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 21613 invoked from network); 19 Apr 2017 19:44:00 +0200
Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 19 Apr 2017 19:43:59 +0200
To: Alia Atlas <akatlas@gmail.com>
References: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> <CAG4d1rcLq=44ToOEA0jokdytjVJvqy3MmwUP5pz-CwVHVa1Lpw@mail.gmail.com>
Cc: The IESG <iesg@ietf.org>, Wesley Eddy <wes@mti-systems.com>, AQM IETF list <aqm@ietf.org>, draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <ietf@kuehlewind.net>
Message-ID: <1f65b8f8-bba9-d695-18d7-c18be522059c@kuehlewind.net>
Date: Wed, 19 Apr 2017 19:43:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAG4d1rcLq=44ToOEA0jokdytjVJvqy3MmwUP5pz-CwVHVa1Lpw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-PPP-Message-ID: <20170419174400.21604.73174@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/JEyFVz1Tn7dUYJc1_hRde87Isa8>
Subject: Re: [aqm] Alia Atlas' Yes on draft-ietf-aqm-codel-07: (with COMMENT)
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 17:50:45 -0000

Hi Alia,

nearly forgot that I quickly want to come back to you on this one.

Actually there is no one good recommendation to make. This is why the working 
ended up standardizing multiple schemes. However, the general guidance given 
in RFC 7567 is to deploy at least one of the solution. And there is also 
RFC7928 that gives guidelines for the characterization of AQM scheme that can 
support operator to evaluate which one fits best their own requirements.

Mirja


On 13.04.2017 15:56, Alia Atlas wrote:
> Hi Mirja,
>
> Thanks for the information.  I completely agree that it is up to the authors,
> shepherd & WG Chairs as to what
> clarity to add.
>
> On the standards track not being required due to not needing interoperability
> with at the same time not enough
> deployment, I do think that having a clear statement would help encourage
> that deployment.  Otherwise, it's a
> catch-22.  I also don't know if codel or fq-codel is actually preferable and
> the reasoning - but I haven't gone and
> reread the latter.   For this work, where the deployment has real hardware
> (ASIC, etc) consequences with long
> lead-times, being clearer would help.
>
> It's nice to see this work moving ahead.
>
> Regards,
> Alia
>
> On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net
> <mailto:ietf@kuehlewind.net>> wrote:
>
>     Hi Alia,
>
>     thanks for your feedback! Just on your first point regarding the status.
>     The working group felt that there was not enough deployment to go
>     directly to standards track and given AQM algorithm don’t need
>     interoperability it was not really important for them to go to standards
>     track right away. However, I leave it to the authors if they are able to
>     add more text on how experimentation should be further performed.
>
>     Mirja
>
>
>
>     > Am 13.04.2017 um 07:28 schrieb Alia Atlas <akatlas@gmail.com
>     <mailto:akatlas@gmail.com>>:
>     >
>     > Alia Atlas has entered the following ballot position for
>     > draft-ietf-aqm-codel-07: 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
>     <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-codel/
>     <https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/>
>     >
>     >
>     >
>     > ----------------------------------------------------------------------
>     > COMMENT:
>     > ----------------------------------------------------------------------
>     >
>     > Thank you for a clear and very well written document.  This was well
>     > worth staying up
>     > past 1am to read fully.  I do have one primary comment and a couple minor
>     > points.
>     >
>     > First, the document status is Experimental.   While encouraging
>     > experimentation, the
>     > document doesn't really articulate what the concerns are or how
>     > experimentation might
>     > determine that this should be changed to standards track.  While
>     > regrettably I haven't
>     > personally followed the AQM work, I might assume that some of the issues
>     > to general
>     > applicability might be tied to aspects around the challenges of applying
>     > CoDel to a
>     > system architecture built around WRED AQM and enqueue complexity rather
>     > than dequeue
>     > complexity.  Having a paragraph that gave context in the introduction for
>     > the questions
>     > still to be explored would be helpful.
>     >
>     > a) In Sec 3.4 :  "This property of CoDel has been exploited in
>     >   fq_codel [FQ-CODEL-ID], which hashes on the packet header fields to
>     >   determine a specific bin, or sub-queue, for each five-tuple flow,"
>     >  For the general case of traffic, it would be better to focus on using a
>     > microflow's
>     >  entropy information  - whether that is derived from a 5-tuple, the IPv6
>     > flow label,
>     >  an MPLS Entropy label, etc.  Tying this specifically to the 5-tuple is
>     > not ideal.
>     >  Obviously I missed this for draft-ietf-aqm-fq-codel-06 - but even a
>     > slight rephrasing
>     > to "for each microflow, identifiable via five-tuple hash, src/dest + IPv6
>     > flow label, or
>     > other entropy information" would encourage better understanding of
>     > micro-flow identification.
>     > Of course, this is just a comment - so do with it what you will.
>     >
>     > b) (Nit) In Sec 5.1: " We use this insight in the pseudo-code for CoDel
>     > later in the draft."
>     >  The pseudo-code is actually earlier in the draft.  Also
>     > s/draft/document for publication.
>     >
>     >
>     > _______________________________________________
>     > aqm mailing list
>     > aqm@ietf.org <mailto:aqm@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/aqm
>     <https://www.ietf.org/mailman/listinfo/aqm>
>
>