From nobody Fri Apr 7 10:44:17 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A04CF1200C5; Fri, 7 Apr 2017 10:44:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org, wes@mti-systems.com, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149158704960.11211.6016773961643040981.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 10:44:09 -0700 Archived-At: Subject: [aqm] Warren Kumari's Yes on draft-ietf-aqm-codel-07: (with COMMENT) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:44:10 -0000 Warren Kumari 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 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think that this is a useful document - I also think that it would make a good introductory document to describe queuing for e.g a collage class. I do have some readability suggestions to make it even better; these do not need any action, but if the authors happen to edit the document for any other reason, they may want to address them. 1: I found the overall structure of the document a little odd -- I'm assuming that this is an artifact of its history, or merging multiple documents into one, or similar. It starts off with a nice description of queuing and CoDel. It then gets all technical with the pseudo-code (which was really helpful). Where it feels a little odd is that it then suddenly goes back to being much more introductory feeling (Section 5 - ), and feels like it repeats some of the earlier material. Reformatting it all to address this seems like overkill, but perhaps a readers note to suggest people who want more background should skip ahead then come back. 2: Section 1. Introduction - "determined set point derived from maximizing the network power metric" -- I'd suggest referencing Section 5.2 where power is explained (or, if we assume readers understand this, section 5.2 can be dropped). 3: Section 3. Overview of the Codel AQM Sojourn time is a really important concept in this document, but it isn't really defined - Section 5.1 is closest to defining it, but still not great. 4: Section 3.1 "The MTU size can be set adaptively to the largest packet seen so far or can be read from the driver." It was unclear what driver -- perhaps "interface driver" or simply "interface"? 5: Section 3.2 has an opening parens but no closing one ("known or measure (though ..."). This is a tiny nit, but set off my OCD tendencies :-) 6: Section 5.1 "We use this insight in the pseudo-code for CoDel later in the draft.) - earlier in the draft... Section 5.2: AIMD TCP could use a reference. From nobody Fri Apr 7 11:02:47 2017 Return-Path: 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 977DA1294E4 for ; Fri, 7 Apr 2017 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rVMfeApqA0RC for ; Fri, 7 Apr 2017 11:02:42 -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 20C2512950A for ; Fri, 7 Apr 2017 11:02:40 -0700 (PDT) Received: (qmail 11556 invoked from network); 7 Apr 2017 20:02:39 +0200 Received: from unknown (HELO ?172.17.52.46?) (66.171.166.114) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 7 Apr 2017 20:02:39 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <149158704960.11211.6016773961643040981.idtracker@ietfa.amsl.com> Date: Fri, 7 Apr 2017 14:02:36 -0400 Cc: The IESG , wes@mti-systems.com, aqm@ietf.org, draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A67DED7-961E-4966-BA3D-FD465CBF32EE@kuehlewind.net> References: <149158704960.11211.6016773961643040981.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [aqm] Warren Kumari's 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:02:44 -0000 Hi Warren, thanks for your comments. There will probably be another version so it = should be easy to incorporate your comments! Also the comment to have = section 5 earlier was made several times; so probably that will happen = as well. Thanks! Mirja > Am 07.04.2017 um 13:44 schrieb Warren Kumari : >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-aqm-codel-07: Yes >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I think that this is a useful document - I also think that it would = make > a good introductory document to describe queuing for e.g a collage = class. >=20 >=20 > I do have some readability suggestions to make it even better; these = do > not need any action, but if the authors happen to edit the document = for > any other reason, they may want to address them. >=20 > 1: I found the overall structure of the document a little odd -- I'm > assuming that this is an artifact of its history, or merging multiple > documents into one, or similar. It starts off with a nice description = of > queuing and CoDel. It then gets all technical with the pseudo-code = (which > was really helpful). Where it feels a little odd is that it then = suddenly > goes back to being much more introductory feeling (Section 5 - ), and > feels like it repeats some of the earlier material. Reformatting it = all > to address this seems like overkill, but perhaps a readers note to > suggest people who want more background should skip ahead then come > back. >=20 > 2: Section 1. Introduction > - "determined set point derived from maximizing the network power = metric" > -- I'd suggest referencing Section 5.2 where power is explained (or, = if > we assume readers understand this, section 5.2 can be dropped). >=20 > 3: Section 3. Overview of the Codel AQM > Sojourn time is a really important concept in this document, but it = isn't > really defined - Section 5.1 is closest to defining it, but still not > great. >=20 > 4: Section 3.1 > "The MTU size can be set adaptively to the largest packet seen so far = or > can be read from the driver." > It was unclear what driver -- perhaps "interface driver" or simply > "interface"? >=20 > 5: Section 3.2 has an opening parens but no closing one ("known or > measure (though ..."). > This is a tiny nit, but set off my OCD tendencies :-) >=20 > 6: Section 5.1 > "We use this insight in the pseudo-code for CoDel later in the = draft.) > - earlier in the draft... >=20 > Section 5.2:=20 > AIMD TCP could use a reference. >=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Fri Apr 7 16:31:04 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 570A31293FF; Fri, 7 Apr 2017 16:30:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org, wes@mti-systems.com, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149160784634.11228.15130249716563575444.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 16:30:46 -0700 Archived-At: Subject: [aqm] Eric Rescorla's No Objection on draft-ietf-aqm-codel-07: (with COMMENT) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:30:46 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-aqm-codel-07: No Objection 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-codel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The normative part of this document seems reasonably clear and I believe I could implement it. Note: I have not attempted to assess the technical quality of the algorithm described in this protocol. I found the descriptive part a little hard to follow in places. Specifically: - It's a little hard to work out which things are informal terms and which are defined terms of art. "power" is used first on page 4 but it's only clear that it's a term of art in S 16. This could be fixed by a forward reference and a cite to Kleinrock. "target" and "interval" are constants in the algorithm, but this wasn't entirely clear to me in S 3.2. You could deal with this by stating in S 3 that the algorithm takes in two variables (TARGET and INTERVAL). Perhaps capitalize them. I see you also use "setpoint" and "target" and "target setpoint". I would stick to one if you can. - It seems that the document went through some reordering because S 5.1. refers to the pseudo-code as coming later in the draft. Perhaps some of the rationale could come before the pseudo-code. Specifically, the intuition that the dropping happens only when you are able to send packets (dequeue) is kind of counter-intuitive. - Following up on the above point, you must be able to drop packets when the queue is entirely full, but S 4.4 doesn't seem to contemplate this. What is the impact of this? You just drop and ignore? Finally, you seem a bit inconsistent about whether you are capitalizing 2119 terms (see for instance the use of should vs. SHOULD in the second graf of S 3.2). From nobody Sun Apr 9 12:06:56 2017 Return-Path: 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 22A6C1243F6 for ; Sun, 9 Apr 2017 12:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 sf3zB9PVH6XV for ; Sun, 9 Apr 2017 12:06:54 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE02126DC2 for ; Sun, 9 Apr 2017 12:06:51 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id i5so23535940pfc.2 for ; Sun, 09 Apr 2017 12:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QvIGLrpVz9kD97Zrf2RshT/leDo8atNgvxKkEWT49CE=; b=Yy1Vz930RMnfaZDk/HzXQFhKYVCdaIQkI8oqlfNjzjBINWjgpmHE8RjT6rn/2SmTrr pPeKWYYLUF3+6pOuEb+StnmgT6z/knRnbsOvubS9scFx7QEuWWgZdpON0jm3QlrXB6e/ XoZ8b6f3dKrUAJt9C/j+CClf/J5NFt3d8PkkpQoT49D4yvEiH4Ma7H1JGNG8YykgW4Et fhuMTwExWMdS8RgVKsy2W2Yk7VdDdiLEFTCZv6mBTtIOuhmxXN+oHopPRMe9L9DZxPqP kn3fKjbGZ79uCEw0DmLkcxU37V7yIBh+ed4kAzmW5vRNWByn3kW+2hSmdt65ZoPoSiDp Heqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QvIGLrpVz9kD97Zrf2RshT/leDo8atNgvxKkEWT49CE=; b=f2ZBYDuMEqoYypnu77bWn7NmhHNrh6btN5UI+bTJNCJmT4Hsp/wyZHXEnzOK1OCLPA Auv6Dd2DJHmNuzAoVY6dFTCCcX4pxWCb8bWFdFSnRllWTC6uch/QZyUjHPHIU3sXJVpK PKNgvvP2rc04r6tSCPSIcHuqioUnuFSHDSB0Vrxge3KjRGriCeaFDmtR6lobDBi1jg0+ Ru6mBYgOmZr4GNyhfAUhQlekxn5jhNqolHRcFREMU6+5ReUaxEmogAZQsHGmLgfGP9no m9XxZcr4VwpVhSWoX6sQ65wmcfpoL2UQ2Fy4ygt/DcvKrbEjPVaquPooYpEXkzlSF9Vh WqXQ== X-Gm-Message-State: AN3rC/5n7+5MqVoTAqjNYO9xw/J9EHFYZuqGaHWAPnnWGAuyQivUrROvrCfNQC2dIQWE20Bn7MM4m8d9b6VSLTjM X-Received: by 10.98.75.152 with SMTP id d24mr7662155pfj.107.1491764811237; Sun, 09 Apr 2017 12:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.209 with HTTP; Sun, 9 Apr 2017 12:06:50 -0700 (PDT) In-Reply-To: <6A67DED7-961E-4966-BA3D-FD465CBF32EE@kuehlewind.net> References: <149158704960.11211.6016773961643040981.idtracker@ietfa.amsl.com> <6A67DED7-961E-4966-BA3D-FD465CBF32EE@kuehlewind.net> From: Jana Iyengar Date: Sun, 9 Apr 2017 12:06:50 -0700 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: Warren Kumari , The IESG , Wesley Eddy , aqm@ietf.org, draft-ietf-aqm-codel@ietf.org, "aqm-chairs@ietf.org" Content-Type: multipart/alternative; boundary=001a113555e0aa00ae054cc08fbe Archived-At: Subject: Re: [aqm] Warren Kumari's 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 19:06:56 -0000 --001a113555e0aa00ae054cc08fbe Content-Type: text/plain; charset=UTF-8 +1 to Mirja's response. I'll do some restructuring. Thanks for your comments! On Fri, Apr 7, 2017 at 11:02 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Warren, > > thanks for your comments. There will probably be another version so it > should be easy to incorporate your comments! Also the comment to have > section 5 earlier was made several times; so probably that will happen as > well. Thanks! > > Mirja > > > > Am 07.04.2017 um 13:44 schrieb Warren Kumari : > > > > Warren Kumari 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 > > 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/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I think that this is a useful document - I also think that it would make > > a good introductory document to describe queuing for e.g a collage class. > > > > > > I do have some readability suggestions to make it even better; these do > > not need any action, but if the authors happen to edit the document for > > any other reason, they may want to address them. > > > > 1: I found the overall structure of the document a little odd -- I'm > > assuming that this is an artifact of its history, or merging multiple > > documents into one, or similar. It starts off with a nice description of > > queuing and CoDel. It then gets all technical with the pseudo-code (which > > was really helpful). Where it feels a little odd is that it then suddenly > > goes back to being much more introductory feeling (Section 5 - ), and > > feels like it repeats some of the earlier material. Reformatting it all > > to address this seems like overkill, but perhaps a readers note to > > suggest people who want more background should skip ahead then come > > back. > > > > 2: Section 1. Introduction > > - "determined set point derived from maximizing the network power metric" > > -- I'd suggest referencing Section 5.2 where power is explained (or, if > > we assume readers understand this, section 5.2 can be dropped). > > > > 3: Section 3. Overview of the Codel AQM > > Sojourn time is a really important concept in this document, but it isn't > > really defined - Section 5.1 is closest to defining it, but still not > > great. > > > > 4: Section 3.1 > > "The MTU size can be set adaptively to the largest packet seen so far or > > can be read from the driver." > > It was unclear what driver -- perhaps "interface driver" or simply > > "interface"? > > > > 5: Section 3.2 has an opening parens but no closing one ("known or > > measure (though ..."). > > This is a tiny nit, but set off my OCD tendencies :-) > > > > 6: Section 5.1 > > "We use this insight in the pseudo-code for CoDel later in the draft.) > > - earlier in the draft... > > > > Section 5.2: > > AIMD TCP could use a reference. > > > > > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm > > --001a113555e0aa00ae054cc08fbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to Mirja's response. I'll do some restructuring= . Thanks for your comments!

On Fri, Apr 7, 2017 at 11:02 AM, Mirja Kuehlewind (IETF) <= span dir=3D"ltr"><ietf@kuehlewind.net> wrote:
Hi Warren,

thanks for your comments. There will probably be another version so it shou= ld be easy to incorporate your comments! Also the comment to have section 5= earlier was made several times; so probably that will happen as well. Than= ks!

Mirja


> Am 07.04.2017 um 13:44 schrieb Warren Kumari <warren@kumari.net>:
>
> Warren Kumari 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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dra= ft-ietf-aqm-codel/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I think that this is a useful document - I also think that it would ma= ke
> a good introductory document to describe queuing for e.g a collage cla= ss.
>
>
> I do have some readability suggestions to make it even better; these d= o
> not need any action, but if the authors happen to edit the document fo= r
> any other reason, they may want to address them.
>
> 1: I found the overall structure of the document a little odd -- I'= ;m
> assuming that this is an artifact of its history, or merging multiple<= br> > documents into one, or similar. It starts off with a nice description = of
> queuing and CoDel. It then gets all technical with the pseudo-code (wh= ich
> was really helpful). Where it feels a little odd is that it then sudde= nly
> goes back to being much more introductory feeling (Section 5 - ), and<= br> > feels like it repeats some of the earlier material. Reformatting it al= l
> to address this seems like overkill, but perhaps a readers note to
> suggest people who want more background should skip ahead then come > back.
>
> 2: Section 1.=C2=A0 Introduction
> - "determined set point derived from maximizing the network power= metric"
> -- I'd suggest referencing Section 5.2 where power is explained (o= r, if
> we assume readers understand this, section 5.2 can be dropped).
>
> 3: Section 3.=C2=A0 Overview of the Codel AQM
> Sojourn time is a really important concept in this document, but it is= n't
> really defined - Section 5.1 is closest to defining it, but still not<= br> > great.
>
> 4: Section 3.1
> "The MTU size can be set adaptively to the largest packet seen so= far or
> can be read from the driver."
> It was unclear what driver -- perhaps "interface driver" or = simply
> "interface"?
>
> 5: Section 3.2 has an opening parens but no closing one ("known o= r
> measure (though ...").
> This is a tiny nit, but set off my OCD tendencies :-)
>
> 6: Section 5.1
> "We use this insight in the=C2=A0 pseudo-code for CoDel later in = the draft.)
> - earlier in the draft...
>
> Section 5.2:
> AIMD TCP could use a reference.
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm


--001a113555e0aa00ae054cc08fbe-- From nobody Tue Apr 11 12:36:19 2017 Return-Path: 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 B2F4512EBCA; Tue, 11 Apr 2017 12:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ZL9C24YL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=df91o2Kf 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 PT7vH-8f8Gt5; Tue, 11 Apr 2017 12:36:10 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A9A12EC9C; Tue, 11 Apr 2017 12:36:09 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 51626209F7; Tue, 11 Apr 2017 15:36:09 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 11 Apr 2017 15:36:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=c+9A1/5kCSeNQVpPt4 45e42nb5ogewT5IVEZkGKpD2g=; b=ZL9C24YLV35njbdTM6cJ6mgzqtVs0d4S9P 4M3mtYp4U/Q8ecBAvm1ZtyD178l1/f75itJz9j2OrBTk64thZqtly6atCfjvQ8uL LFS8r5vRsaivzchnXvHLpKqQTEZx8ZgkEXPmPfXiiYZ3S1oswtgdijJ+e1Zegl/Q M+YCcvAORsj7Tp4h/1F7AwKOiY0iPWNJTNdW/XPSefwRhPuPptVJ8gDK8g2OzTnY YRBOwxT/+ll7YY0wGZwQRrhs+7caey01+I4MkEn6PoJa/ZuBt1likG9LfAECy9mN uuHQL2eT2NmUuPsfss1U6osmqVxGlWDLOvhXmQJ7BjmPzPicvuSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=c+9A1/5kCSeNQVpPt445e42nb5ogewT5IVEZkGKpD2g=; b=df91o2Kf hvPzm3Lmrig5mUJ/ZU90X02UynNYAXouGhE+p05+qWuXAQJyO42ah8EytUrOkllK /T2swGjoDDVfKA9d/fLIMX49LRxGx2eUGyD2DehwtZ9XX9RuaZxrOEPsgZUT1GZE 1uFtO6O8yWN+6hobVlI30ScYNq28ftmjGJAoQrGciOph40j1gtMoHV7uTQGYyUfP F16J5Q5zsLdZX+0kKC+lqNJkNVFZCdQSjp8NnFt+fxNOetEYGof88Hs5yZI5F17U UmuHSGg3A1jPmoLyDR7dHKJb32mVyEzhAXwKcPL+UsMO8z7z/qm3VjzqWeIkoX1i +MMUjMsCJeF+fA== X-ME-Sender: X-Sasl-enc: xFnKCn1b5YHytEQW9ozbT8jVwKtWu3CvWr4Vo7fnuTw1 1491939368 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 53F7324526; Tue, 11 Apr 2017 15:36:08 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149049732959.11830.18161576308900341179@ietfa.amsl.com> Date: Tue, 11 Apr 2017 15:36:06 -0400 Cc: gen-art@ietf.org, draft-ietf-aqm-codel.all@ietf.org, aqm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6708251A-546F-49F7-B8DE-86B2C704A63E@cooperw.in> References: <149049732959.11830.18161576308900341179@ietfa.amsl.com> To: Fernando Gont X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [aqm] [Gen-art] Review of draft-ietf-aqm-codel-07 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:36:13 -0000 Fernando, thanks for your review. Will leave it the authors/WG to = consider your comments. On your major point, personally I don=E2=80=99t = find it problematic for the diagrams to be archived elsewhere, given our = current limitations of ASCII art and the clear presentation in the = referenced doc/session in TSVAREA. Alissa > On Mar 25, 2017, at 11:02 PM, Fernando Gont = wrote: >=20 > Reviewer: Fernando Gont > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-aqm-codel-07 > Reviewer: Fernando Gont > Review Date: 2017-03-25 > IETF LC End Date: 2017-03-27 > IESG Telechat date: 2017-04-13 >=20 > Summary: > The document is well written. However, there seem to be too many > details that are left out in other associated documents. Whereas such > details (including figures) are needed to understand this document, > they should be included here. Either provide full explanations or > summarize the outcome without details (there's text that somehow > relies on the reading finding such figures elsewhere). >=20 >=20 > Major issues: > * Section 5.1, page 16: >> A more detailed explanation with many pictures can be found in >> http://www.ietf.org/proceedings/84/slides/slides-84-tsvarea-4.pdf > . >=20 > Unless I'm missing something, if this document is specifying CoDel, > then all such details should be here. >=20 >=20 > Minor issues: > * General: > The document would benefit from a terminology section. For example, > only well into the I-D one finds definitions of terms such as "sojourn > times" or "target setpoint". Not sure if those terms are supposed to > be trivial/obvious to most people reading this document, but their > non-definition left me trying to figure out what the terms were about > before I was ale to better understand what you were describing. >=20 >=20 >=20 > Page 3, Section 1: >> o simple and efficient implementation (can easily span the > spectrum >> from low-end, linux-based access points and home routers up > to >> high-end commercial router silicon) >=20 > There seems to be an unnecesary implicit "judgement" here, associating > linux-based with low-end, and commercial with high end. I suggest you > modify the text. >=20 >=20 > Page 10: >> count_ =3D (delta > 1 && now - drop_next_ < 16*interval_)? >=20 > For clarity, I'd use additional parenthesis here. >=20 >=20 > Nits/editorial comments:=20 > * Page 17: >> The power vs. f curve for any AIMD TCP is monotone decreasing.=20 >=20 > Please expand the acronym. >=20 >=20 > * Page 17: >> simulation that this result holds for Reno, Cubic, and >> Westwood[TSV84]. >=20 > Missing space. >=20 > Thanks! > Fernando >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Apr 11 12:39:35 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8210D12ECA7; Tue, 11 Apr 2017 12:39:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org, wes@mti-systems.com, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149193956644.15674.16215193553376938457.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 12:39:26 -0700 Archived-At: Subject: [aqm] Alissa Cooper's Yes on draft-ietf-aqm-codel-07: (with COMMENT) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:39:27 -0000 Alissa Cooper 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 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Glad to see this document progress. >From Fernando's Gen-ART review: * Page 17: simulation that this result holds for Reno, Cubic, and Westwood[TSV84]. Missing space. From nobody Wed Apr 12 12:16:35 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3C129468; Wed, 12 Apr 2017 12:16:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org, wes@mti-systems.com, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202458587.15702.11814955152317947911.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 12:16:25 -0700 Archived-At: Subject: [aqm] Benoit Claise's No Objection on draft-ietf-aqm-codel-07: (with COMMENT) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:16:33 -0000 Benoit Claise has entered the following ballot position for draft-ietf-aqm-codel-07: No Objection 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-codel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Same view as Warren point 1. I just wondered: why this section 5 as that position? 1: I found the overall structure of the document a little odd -- I'm assuming that this is an artifact of its history, or merging multiple documents into one, or similar. It starts off with a nice description of queuing and CoDel. It then gets all technical with the pseudo-code (which was really helpful). Where it feels a little odd is that it then suddenly goes back to being much more introductory feeling (Section 5 - ), and feels like it repeats some of the earlier material. Reformatting it all to address this seems like overkill, but perhaps a readers note to suggest people who want more background should skip ahead then come back. From nobody Wed Apr 12 22:28:57 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0281267BB; Wed, 12 Apr 2017 22:28:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org, wes@mti-systems.com, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 22:28:47 -0700 Archived-At: Subject: [aqm] Alia Atlas' Yes on draft-ietf-aqm-codel-07: (with COMMENT) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 05:28:48 -0000 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 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/ ---------------------------------------------------------------------- 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. From nobody Thu Apr 13 03:34:54 2017 Return-Path: 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 CE6471314DC for ; Thu, 13 Apr 2017 03:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 t2MyCYAEIql7 for ; Thu, 13 Apr 2017 03:34:51 -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 23CDF1314D3 for ; Thu, 13 Apr 2017 03:34:50 -0700 (PDT) Received: (qmail 14050 invoked from network); 13 Apr 2017 12:34:48 +0200 Received: from p5dec220c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.12) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Apr 2017 12:34:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 12:34:46 +0200 Cc: The IESG , wes@mti-systems.com, aqm@ietf.org, draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> References: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.3273) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:34:53 -0000 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=E2=80=99t 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 : >=20 > Alia Atlas has entered the following ballot position for > draft-ietf-aqm-codel-07: Yes >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 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. >=20 > 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=20 > 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. >=20 > 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,=20 > 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. >=20 > 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. >=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Thu Apr 13 06:19:26 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10345129469; Thu, 13 Apr 2017 06:19:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org, wes@mti-systems.com, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149208955797.15662.2147146752548912824.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 06:19:17 -0700 Archived-At: Subject: [aqm] Spencer Dawkins' Yes on draft-ietf-aqm-codel-07: (with COMMENT) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 13:19:18 -0000 Spencer Dawkins 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 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a strong Yes on this document, but encourage the authors to work through comments about readability from other ADs. From nobody Thu Apr 13 06:41:07 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E50AE129482; Thu, 13 Apr 2017 06:40:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org, wes@mti-systems.com, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149209085993.15746.9304950848979206299.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 06:40:59 -0700 Archived-At: Subject: [aqm] Kathleen Moriarty's No Objection on draft-ietf-aqm-codel-07: (with COMMENT) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 13:41:00 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-aqm-codel-07: No Objection 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-codel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. I have one question, it seems that problems with CoDel could lead to DoS attacks. I understand that the goal here is reducing buffer bloat, so I would expect to see some discussion in the security considerations section that mentions improved availability from the Confidential, Integrity, Availability security principle discussed along with possible DoS considerations. Please correct me if I'm wrong, otherwise it would be helpful to see some text added. From nobody Thu Apr 13 06:56:23 2017 Return-Path: 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 DFA9F129480; Thu, 13 Apr 2017 06:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5Kkv5DTk83tl; Thu, 13 Apr 2017 06:56:10 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF82129471; Thu, 13 Apr 2017 06:56:10 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id w64so112530567wma.0; Thu, 13 Apr 2017 06:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DFijKGh4mOnjwpRKPQ3ZxWH/+SEpT8SA4aBRBv6p+4s=; b=Ou0ajQ4gnzb5qAzTd1gNEPm/7MqQ57BsSSw5J6F0yAXKCysbTpHCMYIEFPEJgJMXCf ikKLHFHmrXSGsLDiJguC7e+2gpupueKqJSq3yZSEc/D90tuCFjVJlYbvUiFmbEodXMIb eI7s5OgDirmYW6H/SuihGA0J5vmjPeo39AU9Kfyy5OGxEzKI2cuzg2UGNDlMPLBf4VV0 kouBacQcm+wMkIrE9lEF28QOGzs7dSgjMWB0GhNcGWMhPeqCheBcL4ILlhNAGQc87tWO qsCo/Fj3GsIQtnEYS92aAnNoAQAzueKKTr+kQs8ye0gDEaMwDtxR4XAiyrHSjEIZ/9wh 1SMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DFijKGh4mOnjwpRKPQ3ZxWH/+SEpT8SA4aBRBv6p+4s=; b=CVdP+X8BhLRZP2JWrf9yrB7Qsr9icd/rg5PEACtIT2kdbYhabk5VyH3BpKLB5IhjkS Xrt2Kdp/z7APLVOKtuTPjvPc3DKh8xhXkzZyghFMP0nPUaoYJwxERfsrU0Oyt/vvdYa+ flYGVjzBzsaiagL5dMF6g+jY0qJgm4Rl4LWYKnwMQTOviZZlLWaukmC4R0TYqsnRbG35 LJWCH5ASv3HLEZnRHbfVYwA1N5OzIdKdx1VxnKrEfT4JijK/UVW+6it4a+iLugj2iTLF g+HxaiUwCbY9+6NfDAxs229cFGR9dOwvHtZOuozWMpUpIrC9haV9mzqtnrSb8xWLeHWx qPOQ== X-Gm-Message-State: AN3rC/4+8WciZZYGIB+KMstUo6Df6+u4BgGKt0mBh4d/j6faIyKO8QSt sINnNupNMNKgpQWFBOmWSA3NPS1L048U X-Received: by 10.28.130.198 with SMTP id e189mr3411503wmd.96.1492091768375; Thu, 13 Apr 2017 06:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.125 with HTTP; Thu, 13 Apr 2017 06:56:07 -0700 (PDT) In-Reply-To: <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> References: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> From: Alia Atlas Date: Thu, 13 Apr 2017 09:56:07 -0400 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: The IESG , Wesley Eddy , AQM IETF list , draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a114421f6d3935f054d0caf89 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 13:56:13 -0000 --001a114421f6d3935f054d0caf89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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> 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 directl= y > to standards track and given AQM algorithm don=E2=80=99t need interoperab= ility 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 h= ow > experimentation should be further performed. > > Mirja > > > > > Am 13.04.2017 um 07:28 schrieb Alia Atlas : > > > > 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 > > 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/ > > > > > > > > ---------------------------------------------------------------------- > > 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 min= or > > 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 issue= s > > to general > > applicability might be tied to aspects around the challenges of applyin= g > > 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 f= or > > 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 IPv= 6 > > 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 + IP= v6 > > 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 > > https://www.ietf.org/mailman/listinfo/aqm > > --001a114421f6d3935f054d0caf89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Thanks for the information.=C2=A0 I completely agree tha= t 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.=C2=A0 Otherwise, it's a
catch-22.=C2=A0 I also don't know if codel or f= q-codel is actually preferable and the reasoning - but I haven't gone a= nd
reread the latter. =C2=A0 For this work,= where the deployment has real hardware (ASIC, etc) consequences with long<= /div>
lead-times, being clearer would help.
=

It's ni= ce to see this work moving ahead. =C2=A0
Regards,
Alia

On Thu= , Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net<= /a>> wrote:
Hi Alia,

thanks for your feedback! Just on your first point regarding the status. Th= e working group felt that there was not enough deployment to go directly to= standards track and given AQM algorithm don=E2=80=99t need interoperabilit= y 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 ho= w experimentation should be further performed.

Mirja



> Am 13.04.2017 um 07:28 schrieb Alia Atlas <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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dra= ft-ietf-aqm-codel/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Thank you for a clear and very well written document.=C2=A0 This was w= ell
> worth staying up
> past 1am to read fully.=C2=A0 I do have one primary comment and a coup= le minor
> points.
>
> First, the document status is Experimental.=C2=A0 =C2=A0While encourag= ing
> experimentation, the
> document doesn't really articulate what the concerns are or how > experimentation might
> determine that this should be changed to standards track.=C2=A0 While<= br> > regrettably I haven't
> personally followed the AQM work, I might assume that some of the issu= es
> to general
> applicability might be tied to aspects around the challenges of applyi= ng
> CoDel to a
> system architecture built around WRED AQM and enqueue complexity rathe= r
> than dequeue
> complexity.=C2=A0 Having a paragraph that gave context in the introduc= tion for
> the questions
> still to be explored would be helpful.
>
> a) In Sec 3.4 :=C2=A0 "This property of CoDel has been exploited = in
>=C2=A0 =C2=A0fq_codel [FQ-CODEL-ID], which hashes on the packet header = fields to
>=C2=A0 =C2=A0determine a specific bin, or sub-queue, for each five-tupl= e flow,"
>=C2=A0 For the general case of traffic, it would be better to focus on = using a
> microflow's
>=C2=A0 entropy information=C2=A0 - whether that is derived from a 5-tup= le, the IPv6
> flow label,
>=C2=A0 an MPLS Entropy label, etc.=C2=A0 Tying this specifically to the= 5-tuple is
> not ideal.
>=C2=A0 Obviously I missed this for draft-ietf-aqm-fq-codel-06 - but eve= n a
> slight rephrasing
> to "for each microflow, identifiable via five-tuple hash, src/des= t + IPv6
> flow label, or
> other entropy information" would encourage better understanding o= f
> 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."
>=C2=A0 The pseudo-code is actually earlier in the draft.=C2=A0 Also
> s/draft/document for publication.
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm


--001a114421f6d3935f054d0caf89-- From nobody Thu Apr 13 10:20:56 2017 Return-Path: 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 63F19129C1C; Thu, 13 Apr 2017 10:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Xef6ZImPKjbh; Thu, 13 Apr 2017 10:20:41 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B22129C16; Thu, 13 Apr 2017 10:20:41 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2601:646:8501:df5:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 3C98C2130F; Thu, 13 Apr 2017 17:20:36 +0000 (UTC) From: Dave Taht To: Alia Atlas Cc: "Mirja Kuehlewind \(IETF\)" , Wesley Eddy , aqm-chairs@ietf.org, draft-ietf-aqm-codel@ietf.org, The IESG , AQM IETF list , dave.taht@gmail.com References: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> Date: Thu, 13 Apr 2017 10:20:34 -0700 In-Reply-To: (Alia Atlas's message of "Thu, 13 Apr 2017 09:56:07 -0400") Message-ID: <87pogg8brx.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 17:20:45 -0000 Alia Atlas writes: > 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. There seems to be consensus on moving 5 to 2 and a few nits worth fixing - but I'm not an author of the codel draft. > 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 At the time these documents were semi-final (going on 3 years back) it didn't seem like pursuing standards track was the right idea. We still do not have enough deployment data on enough underlying media types - so far we have decent data on cable modems, ethernet, and now wifi. Could use an LTE enodeb and MPLS implementation, at least. > 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 I don't know of any pure codel deployments, what's in the third generation in the field is all fq_codel based, with a little bit of uptake of cake[1] with january's "lede-project" release. still waiting for the first pie based cable modems to appear. still hoping we see more than middle tier vendors than ubnt move forward. Codel's ideas do apply independently to all sorts of queue management problems, not just packets per se', and it seems hard enough to wedge them into a standalone draft. > reread the latter. For this work, where the deployment has real > hardware (ASIC, etc) consequences with long > lead-times, being clearer would help. Well, what I know of the initial fpga attempt - one company went under, another went dark. There's some work that may apply (soon) in cambridge's netfpga project. Certainly hope that there is HW IP in progress! There's plenty of time to standardize, and it seems like a great jump to move from experimental to standards track. On the fq_codel front, we found it advantagous to add a bulk dropper last year[2], and we learned a lot from the fq_codel on wifi effort [3], and recently made a nice fix for locally terminated vpns[4]. Given how long the process has taken I've thought about pulling the fq_codel draft and adding in the insights from those efforts... (but that has been stuck behind the codel draft for 2 years in NEEDREF, review was all done). As it will take another year or two to get back decent data from the field on the wifi front, I think getting out the fq_codel draft as it is, is just fine, and 3 or so more years more we can go *.bis on everything. If there is any one thing I'd like to re-add to the aqm lists' workload it is the standard need for something like "BQL" to manage underlying ring buffers better, as that was the core technology that made doing any level of aqm on high speed ethernet possible. [1] https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/ [2] Bulk dropping and dequeuing: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commi= t/?id=3D9d18562a227874289fda8ca5d117d8f503f1dcca https://lwn.net/Articles/692399/ =20=20=20 [3] "Ending the Anomaly - Achieving Low Latency and Airtime Fairness in WiFi" Toke H=C3=B8iland-J=C3=B8rgensen, Micha=C5=82 Kazior, Dave T=C3=A4ht,= Per Hurtig, Anna Brunstrom https://arxiv.org/abs/1703.00064 [4] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/comm= it/?id=3D264b87fa617e758966108db48db220571ff3d60e > > It's nice to see this work moving ahead.=20 > > Regards, > Alia > > On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) > wrote: > > Hi Alia, >=20=20=20=20=20 > 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=E2=80=99t need interoperability it was not really impor= tant > 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. >=20=20=20=20=20 > Mirja >=20=20=20=20=20 >=20=20=20=20=20 >=20=20=20=20=20 >=20=20=20=20=20 >=20=20=20=20=20 > > Am 13.04.2017 um 07:28 schrieb Alia Atlas : > > > > 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 > > 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/ > > > > > > > > - > --------------------------------------------------------------------- >=20=20=20=20 > > COMMENT: > > - > --------------------------------------------------------------------- >=20=20=20=20 > > > > 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. > > > > >=20=20=20=20=20 > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm >=20=20=20=20=20 >=20=20=20=20=20 > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Thu Apr 13 13:18:34 2017 Return-Path: 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 3487D129A9B; Thu, 13 Apr 2017 13:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sCYfUU4vofRe; Thu, 13 Apr 2017 13:18:23 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9119127077; Thu, 13 Apr 2017 13:18:23 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id g204so14357129oib.2; Thu, 13 Apr 2017 13:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8kyYAYTedRyCxsFuGNon2xPKxllEiF8N03vtIT0Gs+c=; b=mXYyQMs5Rts85n0gULmAxHrJcxJchbESwUrypDn7QarHLO9Hwp973Kz4Ygpi2XY49D 1hYrZzglJjoJvKw0Wo/entpKwcBlWXlu+maudtWXoSMOayMvBigmEKqT3JhXz/4SJZFO rYUjT8VA7fVGUremcKdT13d1UHLghAE80owk1Z9Uo4lBOYOgyJKayeZHJbQOSEUYLVYn 75ScsEYf3VHq7jhBPFz8lD+yMb+RcsibhcX20HBmP//pyJBWIRw59YRRLMuYuAukz61n WlLQfhadMnjLhXCMz9H2qSPUKt1Ml/rlN6DPXZ4CuNDiK77u8tg3GesSRb4AAJSxoxzB Gb5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8kyYAYTedRyCxsFuGNon2xPKxllEiF8N03vtIT0Gs+c=; b=ScaziQ5NcsoJGWta5Y6rp0Np69COYRjNXBX7Yjfr6XF2jOnD5i/zZRhHgk3qMmNEre 85oqqgg/SRLWer5EMmZnruEDcoeworMIcolDUMS3eu9jW5lNqrdDHafK6Ti3iZb3HgcC xZU52UxCoul9cpSbuLkKTNlvMvY9f/X1FWamWiFvWYEV+lXxv2Repd8VGFnrz/j2Rpsp 3J9KXjiaKiE/eBbnno77VSXfmiyKigrdeM/rhlavSjXjP5W2yVbg+yRZZFOj/YytQdry 2u9173anknmTPGJqO1OcxP0U2e9Tp3x+zwOr+rVQPt4/+bYqFl5MlsBfGppF99+OOwrk 9TGg== X-Gm-Message-State: AN3rC/72fGV+rd4+50Vyk0A0qE6i2TUp70a1UhkAAvl+cDoo2by+7EiC gfrUHaXr4WKITpAzOMGyPPQSH7I3rg== X-Received: by 10.157.34.16 with SMTP id o16mr2239295ota.266.1492114703119; Thu, 13 Apr 2017 13:18:23 -0700 (PDT) MIME-Version: 1.0 Sender: gettysjim@gmail.com Received: by 10.74.142.129 with HTTP; Thu, 13 Apr 2017 13:18:22 -0700 (PDT) In-Reply-To: <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> References: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> From: Jim Gettys Date: Thu, 13 Apr 2017 16:18:22 -0400 X-Google-Sender-Auth: dlenNSbAcCtgLVk109Hm_8ibTQI Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: Alia Atlas , Wesley Eddy , aqm-chairs@ietf.org, draft-ietf-aqm-codel@ietf.org, The IESG , "aqm@ietf.org" Content-Type: multipart/alternative; boundary=001a113acc78d7fb14054d1206c1 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 20:18:26 -0000 --001a113acc78d7fb14054d1206c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) < 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 directl= y > to standards track and given AQM algorithm don=E2=80=99t need interoperab= ility 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 h= ow > experimentation should be further performed. > > =E2=80=8BThis should be revisited. fq_codel is the default queue discipline on many/most Linux distributions on the planet at this date. - Jim =E2=80=8B > Mirja > > > > > Am 13.04.2017 um 07:28 schrieb Alia Atlas : > > > > 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 > > 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/ > > > > > > > > ---------------------------------------------------------------------- > > 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 min= or > > 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 issue= s > > to general > > applicability might be tied to aspects around the challenges of applyin= g > > 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 f= or > > 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 IPv= 6 > > 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 + IP= v6 > > 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 > > https://www.ietf.org/mailman/listinfo/aqm > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --001a113acc78d7fb14054d1206c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ap= r 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net&= gt; wrote:
Hi Alia,

thanks for your feedback! Just on your first point regarding the status. Th= e working group felt that there was not enough deployment to go directly to= standards track and given AQM algorithm don=E2=80=99t need interoperabilit= y 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 ho= w experimentation should be further performed.


= =E2=80=8BThis should be revisited.

fq_codel is the default queue discipline on many/most Linux dist= ributions on the planet at this date.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Jim
=E2=80=8B
Mirja



> Am 13.04.2017 um 07:28 schrieb Alia Atlas <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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dra= ft-ietf-aqm-codel/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Thank you for a clear and very well written document.=C2=A0 This was w= ell
> worth staying up
> past 1am to read fully.=C2=A0 I do have one primary comment and a coup= le minor
> points.
>
> First, the document status is Experimental.=C2=A0 =C2=A0While encourag= ing
> experimentation, the
> document doesn't really articulate what the concerns are or how > experimentation might
> determine that this should be changed to standards track.=C2=A0 While<= br> > regrettably I haven't
> personally followed the AQM work, I might assume that some of the issu= es
> to general
> applicability might be tied to aspects around the challenges of applyi= ng
> CoDel to a
> system architecture built around WRED AQM and enqueue complexity rathe= r
> than dequeue
> complexity.=C2=A0 Having a paragraph that gave context in the introduc= tion for
> the questions
> still to be explored would be helpful.
>
> a) In Sec 3.4 :=C2=A0 "This property of CoDel has been exploited = in
>=C2=A0 =C2=A0fq_codel [FQ-CODEL-ID], which hashes on the packet header = fields to
>=C2=A0 =C2=A0determine a specific bin, or sub-queue, for each five-tupl= e flow,"
>=C2=A0 For the general case of traffic, it would be better to focus on = using a
> microflow's
>=C2=A0 entropy information=C2=A0 - whether that is derived from a 5-tup= le, the IPv6
> flow label,
>=C2=A0 an MPLS Entropy label, etc.=C2=A0 Tying this specifically to the= 5-tuple is
> not ideal.
>=C2=A0 Obviously I missed this for draft-ietf-aqm-fq-codel-06 - but eve= n a
> slight rephrasing
> to "for each microflow, identifiable via five-tuple hash, src/des= t + IPv6
> flow label, or
> other entropy information" would encourage better understanding o= f
> 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."
>=C2=A0 The pseudo-code is actually earlier in the draft.=C2=A0 Also
> s/draft/document for publication.
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

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

--001a113acc78d7fb14054d1206c1-- From nobody Thu Apr 13 13:31:10 2017 Return-Path: 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 053FA127077; Thu, 13 Apr 2017 13:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 H5vqxkjsGIRs; Thu, 13 Apr 2017 13:31:06 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34943124B0A; Thu, 13 Apr 2017 13:23:09 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id g204so14379237oib.2; Thu, 13 Apr 2017 13:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8lHbWBBaFVN7Y8eFoi0VMC4CVU0DHc4Vs6g5+nOKueY=; b=TBB23SA87HA9mU7dzzX71v0Hq/U1J9xKVcMEIadLE3u10qjKpFLfNupnVfumevjRob VETHvqvSXRMEHOQo7HUkrr66FLrBE6wnxAGmy+zeLsQ06aiu26CSaC/2w+GIkjTp463N UGEkzgXfiJRI7uuLLfF7XDfaBlUnjxdrK1E/t2cDftzsrLB9WpKuRmpOnnCNqzONiYcJ d7nMFfJ3Xy1wWKsZ88XMgsPPBEdC+OM73DRf3Gts6wyJyJNL22J93Yvb2UzrvcyUfpDe 40WpDSW0ap3CivmTCe9B1fGQpydJvPdLG4m8DRw1IcRJWKLm/2JFW8lx3oqrbyCyolBh 45hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8lHbWBBaFVN7Y8eFoi0VMC4CVU0DHc4Vs6g5+nOKueY=; b=TuSGLWGs4RYSgBGqoLTeu0ABupJGj6zsnq4i8JHxVPApo7/Fv4/koSWb3fOldL87Wm 5eVxtghHq6v0tdD1OohQy3yoKW7EZ0XIBUj2J3lczV+3ZoH+ErAnoLdbim73mc3LJBk4 ttMnHRV2KeNqY5Qb23OhszpQcETaby3iQlWfJZ3Zo06meMCaGGTb6qJKMs5PqBVYYQqE vx2q3SvWXJNAbFyhN4fpPfKr+5+LXl389VT7fb9+TVwcQ3tPFx83uzHmZUAcpxB/ZHqm lH0SVHEfGV/yeYjHR2Ghxcs4/4tu5g/JXlvvSCRwwJM6MvbiQhKTrdw+yKbcUp6SawmX 9c6A== X-Gm-Message-State: AN3rC/4m9NE+c2IlelQoZrLLRAlw7r9kM4e8EvO0uyqep7ekVtgl2Ocs P1lw0KN532VCYVWMdVsQQkIszpoIxEcq X-Received: by 10.157.34.16 with SMTP id o16mr2255540ota.266.1492114988594; Thu, 13 Apr 2017 13:23:08 -0700 (PDT) MIME-Version: 1.0 Sender: gettysjim@gmail.com Received: by 10.74.142.129 with HTTP; Thu, 13 Apr 2017 13:23:08 -0700 (PDT) In-Reply-To: References: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> From: Jim Gettys Date: Thu, 13 Apr 2017 16:23:08 -0400 X-Google-Sender-Auth: KHSjBTMtBNTmTTrdUFJKCyEY9UQ Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: Alia Atlas , Wesley Eddy , aqm-chairs@ietf.org, draft-ietf-aqm-codel@ietf.org, The IESG , "aqm@ietf.org" Content-Type: multipart/alternative; boundary=001a113acc78dbfca5054d121793 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 20:31:08 -0000 --001a113acc78dbfca5054d121793 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 13, 2017 at 4:18 PM, Jim Gettys wrote: > > > On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) < > 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 direct= ly >> to standards track and given AQM algorithm don=E2=80=99t need interopera= bility 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. >> >> > =E2=80=8BThis should be revisited. > > fq_codel is the default queue discipline on many/most Linux distributions > on the planet at this date. > =E2=80=8BActually, I take that back. Codel is present in Linux, but essentially unused; it is there for experimentation=E2=80=8B (to make it easy for people to compare with fq_cod= el, PIE, etc, and to allow the fq_codel spec to reference it. So Experimental is appropriate for Codel, though explaining why would be good. Fq_codel is a different story: it's widely deployed, and there are multiple implementations (I believe the BSD folks finally got their act together). - Jim - Jim > =E2=80=8B > >> Mirja >> >> >> >> > Am 13.04.2017 um 07:28 schrieb Alia Atlas : >> > >> > 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 thi= s >> > introductory paragraph, however.) >> > >> > >> > Please refer to https://www.ietf.org/iesg/stat >> ement/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/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > 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 issu= es >> > to general >> > applicability might be tied to aspects around the challenges of applyi= ng >> > CoDel to a >> > system architecture built around WRED AQM and enqueue complexity rathe= r >> > 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 IP= v6 >> > flow label, >> > an MPLS Entropy label, etc. Tying this specifically to the 5-tuple i= s >> > 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 CoDe= l >> > 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 >> > https://www.ietf.org/mailman/listinfo/aqm >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >> > > --001a113acc78dbfca5054d121793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ap= r 13, 2017 at 4:18 PM, Jim Gettys <jg@freedesktop.org> wrot= e:


On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF= ) <ietf@kuehlewind.net> wrote:
=
Hi Alia,

thanks for your feedback! Just on your first point regarding the status. Th= e working group felt that there was not enough deployment to go directly to= standards track and given AQM algorithm don=E2=80=99t need interoperabilit= y 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 ho= w experimentation should be further performed.


=E2=80=8BThis should be revisited.
<= br>
fq_codel is the default queue disci= pline on many/most Linux distributions on the planet at this date.

=E2=80=8BActually, I take that back.

Codel is present in Linux, but essential= ly unused; it is there for experimentation=E2=80=8B (to make it easy for pe= ople to compare with fq_codel, PIE, etc, and to allow the fq_codel spec to = reference it.
<= br>
So Experime= ntal is appropriate for Codel, though explaining why would be good.=C2=A0 F= q_codel is a different story: it's widely deployed, and there are multi= ple implementations (I believe the BSD folks finally got their act together= ).
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 - Jim

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- Jim
=E2=80=8B
Mirja



> Am 13.04.2017 um 07:28 schrieb Alia Atlas <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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dra= ft-ietf-aqm-codel/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Thank you for a clear and very well written document.=C2=A0 This was w= ell
> worth staying up
> past 1am to read fully.=C2=A0 I do have one primary comment and a coup= le minor
> points.
>
> First, the document status is Experimental.=C2=A0 =C2=A0While encourag= ing
> experimentation, the
> document doesn't really articulate what the concerns are or how > experimentation might
> determine that this should be changed to standards track.=C2=A0 While<= br> > regrettably I haven't
> personally followed the AQM work, I might assume that some of the issu= es
> to general
> applicability might be tied to aspects around the challenges of applyi= ng
> CoDel to a
> system architecture built around WRED AQM and enqueue complexity rathe= r
> than dequeue
> complexity.=C2=A0 Having a paragraph that gave context in the introduc= tion for
> the questions
> still to be explored would be helpful.
>
> a) In Sec 3.4 :=C2=A0 "This property of CoDel has been exploited = in
>=C2=A0 =C2=A0fq_codel [FQ-CODEL-ID], which hashes on the packet header = fields to
>=C2=A0 =C2=A0determine a specific bin, or sub-queue, for each five-tupl= e flow,"
>=C2=A0 For the general case of traffic, it would be better to focus on = using a
> microflow's
>=C2=A0 entropy information=C2=A0 - whether that is derived from a 5-tup= le, the IPv6
> flow label,
>=C2=A0 an MPLS Entropy label, etc.=C2=A0 Tying this specifically to the= 5-tuple is
> not ideal.
>=C2=A0 Obviously I missed this for draft-ietf-aqm-fq-codel-06 - but eve= n a
> slight rephrasing
> to "for each microflow, identifiable via five-tuple hash, src/des= t + IPv6
> flow label, or
> other entropy information" would encourage better understanding o= f
> 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."
>=C2=A0 The pseudo-code is actually earlier in the draft.=C2=A0 Also
> s/draft/document for publication.
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

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


--001a113acc78dbfca5054d121793-- From nobody Tue Apr 18 06:40:42 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF74112EC4E; Tue, 18 Apr 2017 06:40:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: wes@mti-systems.com, ietf@kuehlewind.net, aqm-chairs@ietf.org, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149252284088.16093.3939390476098786915.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 06:40:40 -0700 Archived-At: Subject: [aqm] aqm - Not having a session at IETF 99 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion list for active queue management and flow isolation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:40:41 -0000 Wesley Eddy, a chair of the aqm working group, indicated that the aqm working group does not plan to hold a session at IETF 99. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Apr 19 10:50:53 2017 Return-Path: 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 ; 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 ; 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 ; 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 References: <149206132767.15808.9810252342515150127.idtracker@ietfa.amsl.com> <04F54465-4A6A-45A0-84A2-6F01A7B9D4C6@kuehlewind.net> Cc: The IESG , Wesley Eddy , AQM IETF list , draft-ietf-aqm-codel@ietf.org, aqm-chairs@ietf.org From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= 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: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) > 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 >: > > > > 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 > > > 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/ > > > > > > > > > ---------------------------------------------------------------------- > > 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 > > https://www.ietf.org/mailman/listinfo/aqm > > >