From nobody Mon Oct 2 12:13: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 D478D13479C for ; Mon, 2 Oct 2017 12:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YdY5MsGtllFl for ; Mon, 2 Oct 2017 12:13:53 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1794E1347AA for ; Mon, 2 Oct 2017 12:13:53 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0: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 AB52121425 for ; Mon, 2 Oct 2017 19:13:50 +0000 (UTC) From: Dave Taht To: aqm@ietf.org Cc: References: <150673314895.3200.13535985478471790173@ietfa.amsl.com> Date: Mon, 02 Oct 2017 12:13:49 -0700 In-Reply-To: <150673314895.3200.13535985478471790173@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 29 Sep 2017 17:59:08 -0700") Message-ID: <8760bxcqhe.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 Archived-At: Subject: Re: [aqm] I-D Action: draft-ietf-aqm-codel-09.txt 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: Mon, 02 Oct 2017 19:13:55 -0000 I have reviewed this draft, and my only complaint is that the new text: "Packets arriving at a full buffer SHOULD be dropped" is really jarring, where it landed, in section 4.4. If this MUST be discussed somewhere, I'd suggest opening a new section for it entirely. Still... I'd suggest dropping this sentence entirely and letting the fq_codel draft handle it. There are, incidentally, several strategies for a dealing with a full buffer in a multi-queue system besides drop tail (which the above appears to recommend for codel). How fq_codel does drop on full, incidentally, has improved greatly since we created the last version of the fq_codel draft, based on field testing. https://patchwork.ozlabs.org/patch/617307/ And I'd be willing to update some future fq_codel.bis document to reflect that. ... I like the new definitions section. ... Aside from that, I have not looked at this in going on two years, and bits are falling out of date, and NONE of my nits are substantive enough to warrant holding up publication a microsecond longer. It's a *experimental* draft, not a standard. If we want to discuss how to produce a fq_codel.bis and codel.bis, and for that matter pie.bis and fq_pie.bis... on standards track, one day, great. internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Active Queue Management and Packet Scheduling WG of the IETF. > > Title : Controlled Delay Active Queue Management > Authors : Kathleen Nichols > Van Jacobson > Andrew McGregor > Janardhan Iyengar > Filename : draft-ietf-aqm-codel-09.txt > Pages : 25 > Date : 2017-09-29 > > Abstract: > This document describes a general framework called CoDel (Controlled > Delay) that controls bufferbloat-generated excess delay in modern > networking environments. CoDel consists of an estimator, a setpoint, > and a control loop. It requires no configuration in normal Internet > deployments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-aqm-codel-09 > https://datatracker.ietf.org/doc/html/draft-ietf-aqm-codel-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-codel-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Thu Oct 5 04:26:01 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 C042B1342CA for ; Thu, 5 Oct 2017 04:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 y5xoPbyAVdbO for ; Thu, 5 Oct 2017 04:25:58 -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 922A0134231 for ; Thu, 5 Oct 2017 04:25:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=j1CJYojaKD6apHhipiCLAoILkmM80ky5vThJmc1AbmHwPEqpmKf2L27BAKheDnRllThXRoQq7yPdNv/Kwp7xbIkJov7Rp/tYUPzMm8KOlb0QB7H0PRDD6S+ZpZtGWNlsR+M3vMMzlfIAhxQB6JVR7kzHZLI2FnI+idH4KI/mK9Y=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 14262 invoked from network); 5 Oct 2017 13:25:53 +0200 Received: from pd9e119f3.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.25.243) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Oct 2017 13:25:53 +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: Date: Thu, 5 Oct 2017 13:25:51 +0200 Cc: aqm@ietf.org, "aqm-chairs@ietf.org" , Van Jacobson , Andrew McGregor , Kathleen Nichols Content-Transfer-Encoding: quoted-printable Message-Id: <727F4E15-6D92-4A56-AAC6-573652E98F67@kuehlewind.net> References: To: Jana Iyengar X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20171005112553.14253.71476@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [aqm] CoDel: After much ado ... 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, 05 Oct 2017 11:26:00 -0000 Hi Jana, thanks see below. > Am 30.09.2017 um 03:01 schrieb Jana Iyengar : >=20 > Mirja, >=20 > Thanks for you review -- apologies for not addressing everything. I = had left a few things out as not necessary to change the draft, but = we've now made the following changes in draft-ietf-aqm-codel-09. >=20 > 1) Did you also check the sec-art and gen-art review. Both, as well as = some ADs, suggested to (better) define such terms as Sojourn time, = estimator, or Interval. Would it make sense to add something to the = terminology section, or did you decide this is not needed? >=20 > We've added these definitons now in Section 2. Thanks! > =20 > 2) Did you see Alia=E2=80=99s comments on mircoflows? I think it is = true that in some cases you may also want to use additional information = like the flow label or DSCP and not just the 5-tuple, while the text = explicitly talks about 5-tuples. Do you want to add something here, or = did you on purpose decide to only restrict to 5-tuples? I thinks this = may be an unnecessary restriction and probably was not meant to be one. >=20 > We fixed the draft to remove mentions of 5-tuples. (This was already = done in -08.) Okay. I was wondering if you want to explain more explicitly what flow = means, by e.g. saying something like it can be not only a 5-tuple but = e.g. could also include DSCP but that is implementation dependent=E2=80=A6= ? > =20 > 3) Did you see this comment from Ekr: > "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?=E2=80=9C > Can you explain how this was addressed? Maybe I just missed that but = it seems important. >=20 > There's nothing to be done if a packet arrives at a full buffer = besides dropping it... we've added a sentence now that says "Packets = arriving at a full buffer SHOULD be dropped." Hopefully that should = clarify things. The point here was rather the question if you count these as drop or not = in your algorithm. I believe you don=E2=80=99t count them but only those = packets that actually get dropped by CoDel directly, right?=20 However, I don=E2=80=99t think using normative language in the sentences = you=E2=80=99ve added makes sense because, as you say, drop is the only = thing you can do. I guess you=E2=80=99d need to say something like this = instead: "Packets arriving at a full buffer will be dropped. These packets are = not counted for the calculation of the CoDel algorithm.=E2=80=9C Or something similar=E2=80=A6 Please let me know what you think and either update the draft, or we can = also just add an RFC Editor not if that=E2=80=99s easier=E2=80=A6 Mirja =20 >=20 > Hope this covers everything that's pending -- let me know if I've = missed anything. >=20 > (I received jim-jam biscuits/cookies from Jim Gettys which helped with = this round -- thanks Jim :-)) >=20 > >=20 > - jana >=20 > Thanks! > Mirja >=20 >=20 >=20 >=20 > > Am 12.09.2017 um 02:27 schrieb Jana Iyengar : > > > > ... draft-ietf-aqm-codel-08 is finally posted. This new version = addresses all IESG comments during IESG review, in addition to review = comments by Patrick Timmons and Yoav Nir. We thank everyone for their = help with reviews. > > > > Most importantly, I want to personally thank the fq_codel authors = for sending me Yerba Mate, Dave Taht for sending me delicious = freshly-baked cookies, and Paul McKenney for sending me a ton of organic = green tea to help me move on the document. I will say that you all = managed to do something nobody has managed so far: you successfully = shamed me into getting this work done. > > > > I also received bungee cords from the fq_codel authors to tie myself = to my chair with, which I put to good use: I would like to share here = evidence of my atonement. (Cookies are not in the picture, because they = were delicious. Thanks, Dave!) > > > > - jana > > > > (P.S.: I now look forward to receiving thank you gifts. Oh, and I'm = caffeine-free and vegetarian, just in case.) > > >=20 >=20 From nobody Fri Oct 13 23:26:15 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 0F4E5124B17; Fri, 13 Oct 2017 23:26:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150796236901.5182.6456785452286232870@ietfa.amsl.com> Date: Fri, 13 Oct 2017 23:26:09 -0700 Archived-At: Subject: [aqm] I-D Action: draft-ietf-aqm-codel-10.txt 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: Sat, 14 Oct 2017 06:26:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Active Queue Management and Packet Scheduling WG of the IETF. Title : Controlled Delay Active Queue Management Authors : Kathleen Nichols Van Jacobson Andrew McGregor Janardhan Iyengar Filename : draft-ietf-aqm-codel-10.txt Pages : 25 Date : 2017-10-13 Abstract: This document describes a general framework called CoDel (Controlled Delay) that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-aqm-codel-10 https://datatracker.ietf.org/doc/html/draft-ietf-aqm-codel-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-codel-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 13 23:31:32 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 2A4C0132D22 for ; Fri, 13 Oct 2017 23:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 8Mx_j7vRWK9A for ; Fri, 13 Oct 2017 23:31:27 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 38FDA124207 for ; Fri, 13 Oct 2017 23:31:27 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id n61so23279747qte.10 for ; Fri, 13 Oct 2017 23:31:27 -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=tr/sohYCu/noTj/nRYCOapdA8YuRYrqKg0/jzi0RQwU=; b=jtyRnjsW0gNe90V5R6YVIDZftmrxHe0kRHA54s9AP8IZ6fzjNW+I8WdWHfOIqanudk quezCT8SBqm1woS7BNI0gEbFJltINDSYRaXFNB44Kw3iU+oSscOyvrnvBKemlLX855Nb +nqXwF9LCCNtzgRuNNY5RLwUPpdiqqMmVYexQk5yiS3/CBsXYU+MvAcj0UNJp+x+w87f 0EnVderdE8N/3UB+At7Bz/Gg5QP2x/2uLfxRuhBfpSz/RO1I3C55GeHwWxukwFYYJr1L 0BIK50L+uoe0fHBCUeIWkxmsblf+6Ra9JzuZDjd5CRStgSD1jIVc4QhNjQsqLFFGiGzy YWkg== 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=tr/sohYCu/noTj/nRYCOapdA8YuRYrqKg0/jzi0RQwU=; b=uLzg5I4Q0KQvdB6WT8cECzA2aZ4FLXDK2mYBkhvzOF2vnULpD/FHOs1kLgYAFittgi hGpvdsBoyWqtcbqJ9UJQ96R4RxeDYIGAOwjkSykRyjIc/Yl4v0jswj9ftc94ydMU+beP A5r+58Xywe44vpDNOIWnqvoSd35TRGh8hy5DUyaENthhJeMgec9hggLX6v2dpBIuA7k4 aNI0LYCvOrtA2bNNscJaNVm6TEGRlvFROXBlGkrLHolxUuGV+oZlsjottuBlBmDrBrxP EsDfRSnMxuX7F/7ODwdJe+EcAYPyXg0SF2Mj3kPfa1qzeZtxwp5uy3cAE3dgjtQpkYui tbAQ== X-Gm-Message-State: AMCzsaXHblGIbgZb7RHM4nkJyBG8fDzIIi+/okFEDW2+F/AWAGbZ4EB7 B1ad/tEki8DRQb26zX+YNF25iqC7XeU25jH+Dy+x2Q== X-Google-Smtp-Source: AOwi7QDFbMhyauRpM/3Mt8dFux03pLa3EhgnmqX+/BCSOXOn9ssVA1u3V20zR8Aq1DrQbkTSQknnOyDrsLoeozgS+jU= X-Received: by 10.37.78.133 with SMTP id c127mr2264302ybb.398.1507962686111; Fri, 13 Oct 2017 23:31:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Fri, 13 Oct 2017 23:31:25 -0700 (PDT) In-Reply-To: <727F4E15-6D92-4A56-AAC6-573652E98F67@kuehlewind.net> References: <727F4E15-6D92-4A56-AAC6-573652E98F67@kuehlewind.net> From: Jana Iyengar Date: Fri, 13 Oct 2017 23:31:25 -0700 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: aqm@ietf.org, "aqm-chairs@ietf.org" , Van Jacobson , Andrew McGregor , Kathleen Nichols Content-Type: multipart/alternative; boundary="001a113e96023e1beb055b7becff" Archived-At: Subject: Re: [aqm] CoDel: After much ado ... 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: Sat, 14 Oct 2017 06:31:30 -0000 --001a113e96023e1beb055b7becff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, I've posted -10 of the draft , see more below. > > 2) Did you see Alia=E2=80=99s comments on mircoflows? I think it is tru= e that in > some cases you may also want to use additional information like the flow > label or DSCP and not just the 5-tuple, while the text explicitly talks > about 5-tuples. Do you want to add something here, or did you on purpose > decide to only restrict to 5-tuples? I thinks this may be an unnecessary > restriction and probably was not meant to be one. > > > > We fixed the draft to remove mentions of 5-tuples. (This was already > done in -08.) > > Okay. I was wondering if you want to explain more explicitly what flow > means, by e.g. saying something like it can be not only a 5-tuple but e.g= . > could also include DSCP but that is implementation dependent=E2=80=A6? I really do not want to get into defining a flow; I think this works for any definition of flow, since that's ultimately implementation dependent. Any implementation can (as they do) assume whatever they want in terms of defining a flow. > > 3) Did you see this comment from Ekr: > > "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?=E2=80=9C > > Can you explain how this was addressed? Maybe I just missed that but it > seems important. > > > > There's nothing to be done if a packet arrives at a full buffer besides > dropping it... we've added a sentence now that says "Packets arriving at = a > full buffer SHOULD be dropped." Hopefully that should clarify things. > > The point here was rather the question if you count these as drop or not > in your algorithm. I believe you don=E2=80=99t count them but only those = packets > that actually get dropped by CoDel directly, right? > > However, I don=E2=80=99t think using normative language in the sentences = you=E2=80=99ve > added makes sense because, as you say, drop is the only thing you can do.= I > guess you=E2=80=99d need to say something like this instead: > > "Packets arriving at a full buffer will be dropped. These packets are not > counted for the calculation of the CoDel algorithm.=E2=80=9C > > Or something similar=E2=80=A6 > I've removed normative language (Dave Taht also didn't like it) and replaced it with some text about how it's not really used for CoDel computations. I've also moved it to later in the draft where it fits better. I've also taken in some other editorial nits that I received from Lixia Zhang in the meanwhile (Thanks, Lixia!). Thanks all! - jana --001a113e96023e1beb055b7becff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

I've posted -10 of the draft, se= e more below.
=C2=A0
> 2) Did = you see Alia=E2=80=99s comments on mircoflows? I think it is true that in s= ome cases you may also want to use additional information like the flow lab= el or DSCP and not just the 5-tuple, while the text explicitly talks about = 5-tuples. Do you want to add something here, or did you on purpose decide t= o only restrict to 5-tuples? I thinks this may be an unnecessary restrictio= n and probably was not meant to be one.
>
> We fixed the draft to remove mentions of 5-tuples. (This was already d= one in -08.)

Okay. I was wondering if you want to explain more explicitly what fl= ow means, by e.g. saying something like it can be not only a 5-tuple but e.= g. could also include DSCP but that is implementation dependent=E2=80=A6?

I really do not want to get into defining a = flow; I think this works for any definition of flow, since that's ultim= ately implementation dependent. Any implementation can (as they do) assume = whatever they want in terms of defining a flow.
=C2=A0
> 3) Did you see this comment from Ekr:
> "Following up on the above point, you must be able to
>=C2=A0 =C2=A0drop packets when the queue is entirely full, but S
>=C2=A0 =C2=A04.4 doesn't seem to contemplate this. What is the impa= ct
>=C2=A0 =C2=A0of this? You just drop and ignore?=E2=80=9C
> Can you explain how this was addressed? Maybe I just missed that but i= t seems important.
>
> There's nothing to be done if a packet arrives at a full buffer be= sides dropping it... we've added a sentence now that says "Packets= arriving at a full buffer SHOULD be dropped." Hopefully that should c= larify things.

The point here was rather the question if you count these as drop or= not in your algorithm. I believe you don=E2=80=99t count them but only tho= se packets that actually get dropped by CoDel directly, right?

However, I don=E2=80=99t think using normative language in the sentences yo= u=E2=80=99ve added makes sense because, as you say, drop is the only thing = you can do. I guess you=E2=80=99d need to say something like this instead:<= br>
"Packets arriving at a full buffer will be dropped. These packets are = not counted for the calculation of the CoDel algorithm.=E2=80=9C

Or something similar=E2=80=A6

I've = removed normative language (Dave Taht also didn't like it) and replaced= it with some text about how it's not really used for CoDel computation= s. I've also moved it to later in the draft where it fits better.=C2=A0=

I've also taken in some other editorial nits = that I received from Lixia Zhang in the meanwhile (Thanks, Lixia!).=C2=A0

Thanks all!
- jana
--001a113e96023e1beb055b7becff-- From nobody Mon Oct 16 01:43:03 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 D100C134493 for ; Mon, 16 Oct 2017 01:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 3i4q8KZE2RtH for ; Mon, 16 Oct 2017 01:42:59 -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 93E58134498 for ; Mon, 16 Oct 2017 01:42:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=OtdEMwYzcOQNEyciFCCeiS6VSeJb3sdZgWjKs58m9ZzxozOQUGcaT5WqtXt0rV+KA5CMQfJqcElAc+mp4f6FDsPTQMNiI1aAtMqkwMeVf/5cD40dGr5kR8MDKW7V9D5XXaGlx1Pg0XHa24lpQle8824c9WZjDyMtBdy6wS/etCY=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1617 invoked from network); 16 Oct 2017 10:42:56 +0200 Received: from p5dec287e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.40.126) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Oct 2017 10:42:56 +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: Date: Mon, 16 Oct 2017 10:42:54 +0200 Cc: aqm@ietf.org, "aqm-chairs@ietf.org" , Van Jacobson , Andrew McGregor , Kathleen Nichols Content-Transfer-Encoding: quoted-printable Message-Id: <1886F711-C7B1-415C-8F43-5691E54EDA51@kuehlewind.net> References: <727F4E15-6D92-4A56-AAC6-573652E98F67@kuehlewind.net> To: Jana Iyengar X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20171016084256.1608.39832@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [aqm] CoDel: After much ado ... 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: Mon, 16 Oct 2017 08:43:02 -0000 Thanks! Will approve now! Finally! Yeah! > Am 14.10.2017 um 08:31 schrieb Jana Iyengar : >=20 > Hi Mirja, >=20 > I've posted -10 of the draft, see more below. > =20 > > 2) Did you see Alia=E2=80=99s comments on mircoflows? I think it is = true that in some cases you may also want to use additional information = like the flow label or DSCP and not just the 5-tuple, while the text = explicitly talks about 5-tuples. Do you want to add something here, or = did you on purpose decide to only restrict to 5-tuples? I thinks this = may be an unnecessary restriction and probably was not meant to be one. > > > > We fixed the draft to remove mentions of 5-tuples. (This was already = done in -08.) >=20 > Okay. I was wondering if you want to explain more explicitly what flow = means, by e.g. saying something like it can be not only a 5-tuple but = e.g. could also include DSCP but that is implementation dependent=E2=80=A6= ? >=20 > I really do not want to get into defining a flow; I think this works = for any definition of flow, since that's ultimately implementation = dependent. Any implementation can (as they do) assume whatever they want = in terms of defining a flow. > =20 > > 3) Did you see this comment from Ekr: > > "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?=E2=80=9C > > Can you explain how this was addressed? Maybe I just missed that but = it seems important. > > > > There's nothing to be done if a packet arrives at a full buffer = besides dropping it... we've added a sentence now that says "Packets = arriving at a full buffer SHOULD be dropped." Hopefully that should = clarify things. >=20 > The point here was rather the question if you count these as drop or = not in your algorithm. I believe you don=E2=80=99t count them but only = those packets that actually get dropped by CoDel directly, right? >=20 > However, I don=E2=80=99t think using normative language in the = sentences you=E2=80=99ve added makes sense because, as you say, drop is = the only thing you can do. I guess you=E2=80=99d need to say something = like this instead: >=20 > "Packets arriving at a full buffer will be dropped. These packets are = not counted for the calculation of the CoDel algorithm.=E2=80=9C >=20 > Or something similar=E2=80=A6 >=20 > I've removed normative language (Dave Taht also didn't like it) and = replaced it with some text about how it's not really used for CoDel = computations. I've also moved it to later in the draft where it fits = better.=20 >=20 > I've also taken in some other editorial nits that I received from = Lixia Zhang in the meanwhile (Thanks, Lixia!).=20 >=20 > Thanks all! > - jana From nobody Mon Oct 16 02:29:37 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 01BF31344B1; Mon, 16 Oct 2017 02:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=toke.dk 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 GVWQWcbhCG3n; Mon, 16 Oct 2017 02:29:34 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1051E132944; Mon, 16 Oct 2017 02:29:34 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1508146164; bh=ElwblJy0I0mGYUK/KMOlkjHga1Wa5sAjNSdO3JyNTkk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=sbOrax/Pp7JQ7L/bDEhvcTR6PgIexi05D2I5yABdOkKNsC7glDcPKTRXHobnSpfA0 5NSJ4QBik7VzTnMK5hiS62UeV4H2hMR4/QyLenXXOsxRFxWJE5RR2y7cTTK7iuI0Ho MNkbW79aAJ/jq2hq56YqCluPYczZ+jrhWSjfkOPzAq9kSkVMPzgYpQg4Y5RMJHMMzz t43FEf+sLB7jFXJDpxJiWWaIREuF/Pb/wARYN0RhFFnpsbovao94eZRXSH6uahNfdh WuB1nZ3ioPKwZuhVDk8jY6YZWQt9mTyiFWOVjp3KkJ5y5wI7TzAiZLhunzJ0Khe4TD WWIsDuwdg5LSw== To: "Mirja Kuehlewind \(IETF\)" , Jana Iyengar Cc: Andrew McGregor , Kathleen Nichols , aqm@ietf.org, Van Jacobson , "aqm-chairs\@ietf.org" In-Reply-To: <1886F711-C7B1-415C-8F43-5691E54EDA51@kuehlewind.net> References: <727F4E15-6D92-4A56-AAC6-573652E98F67@kuehlewind.net> <1886F711-C7B1-415C-8F43-5691E54EDA51@kuehlewind.net> Date: Mon, 16 Oct 2017 11:29:22 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1zva1al.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [aqm] CoDel: After much ado ... 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: Mon, 16 Oct 2017 09:29:36 -0000 "Mirja Kuehlewind (IETF)" writes: > Thanks! Will approve now! Finally! Yeah! And there was much rejoicing! Wooh! :) -Toke From nobody Mon Oct 16 04:50:20 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 606E51344BE for ; Mon, 16 Oct 2017 04:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 b07uJwfo95bG for ; Mon, 16 Oct 2017 04:50:17 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 CEB071344BC for ; Mon, 16 Oct 2017 04:50:17 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id b85so15614510pfj.13 for ; Mon, 16 Oct 2017 04:50:17 -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=wVFjK8U0tYu9wb6u4jNE0u3Uy00+4/At33a5iN5TGjY=; b=MIINfS8Dg7x8U3soV3BrxB/tCwAvbz38p3lrlHgDqEttl+G7jVZi65RysoGNeniCvp YGIh2fbD0sy4U/U6kMlFzT6KFbgWGn3g+wn0TcVH6M4EQJHFhnhJiccM3d7VcV1Q80Yr vae5+YgePyy4Aw7tKqrNmNg9ffKTq3DVpkO0joQOwMRNRxBBzG/xD2cCcWsgdj01BfMy H/vU1IYcMc65brmzmRntlyVHEVnWsw+I8H0ygGxtJFtB8cB1ZErl5uyn5mmPUuFVNoiZ hc4Uhh4jfE5JmwshYhppSyfUOfpbPg2MAzz59uvUw7wlGQmBNR781wW+Ue/GCwShXWvU 8PtA== 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=wVFjK8U0tYu9wb6u4jNE0u3Uy00+4/At33a5iN5TGjY=; b=STV7QvBsjZRo4kaWLTA9GzEUEML2YOHjR28osMO/FLP3rgvkO80iKxRTkmk1Ysmtfl CATY/TUWkfVXUOSlVa9mDumrv7Ii912RRJsnegyfxryyr5VT/egwRbEU/reCVGGVwT+E 9ineuP24kIFizw+5fXRCaRIkqvnC1R42Ar+9KWrJdhOb8j6L6ssGjtbyBYzTR5N/x+0Z V1xk7Mma9rlZpe0ahEjO4AtWPFprhoEioGmV1CS3U8Ji27XyiXArDfSfBS3604pUeU4r 5w14P02YO5N2MlVWp00fhLxhfOSKgvLU4HtBTEfqJUX/hkEyIkPLgoW0hIu5z65n+LU5 M2rQ== X-Gm-Message-State: AMCzsaVx5FvK4excG3/k7xcPFyOcMFTvZnp8cPmiOBBIevBpFF92C69W HqWUqI/htVqMyLx94q3CQdjyyobi11Q+aqs9iDQUfw== X-Google-Smtp-Source: AOwi7QCUIKE7CT+nFSX40gXdc0JCv8pMltpq/RpiLccZCnMory+OWrDqI7aZZb2JEgv8JbgznmUp7xQluF/K2TDsEe4= X-Received: by 10.99.140.8 with SMTP id m8mr8054703pgd.23.1508154617210; Mon, 16 Oct 2017 04:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.174.195 with HTTP; Mon, 16 Oct 2017 04:50:16 -0700 (PDT) In-Reply-To: <87k1zva1al.fsf@toke.dk> References: <727F4E15-6D92-4A56-AAC6-573652E98F67@kuehlewind.net> <1886F711-C7B1-415C-8F43-5691E54EDA51@kuehlewind.net> <87k1zva1al.fsf@toke.dk> From: Andrew Mcgregor Date: Mon, 16 Oct 2017 22:50:16 +1100 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: "Mirja Kuehlewind (IETF)" , Jana Iyengar , Kathleen Nichols , "aqm@ietf.org" , Van Jacobson , "aqm-chairs@ietf.org" Content-Type: multipart/alternative; boundary="f403045e1ff23a5f41055ba89c6d" Archived-At: Subject: Re: [aqm] CoDel: After much ado ... 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: Mon, 16 Oct 2017 11:50:19 -0000 --f403045e1ff23a5f41055ba89c6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Win! On 16 October 2017 at 20:29, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > "Mirja Kuehlewind (IETF)" writes: > > > Thanks! Will approve now! Finally! Yeah! > > And there was much rejoicing! Wooh! :) > > -Toke > --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --f403045e1ff23a5f41055ba89c6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Win!

On 16 October 2017 at 20:29, Toke H=C3=B8iland-J=C3=B8rgensen <toke@t= oke.dk> wrote:
"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> writes:

> Thanks! Will approve now! Finally! Yeah!

And there was much rejoicing! Wooh! :)

-Toke



--
Andrew McGregor=C2= =A0|=C2=A0SRE=C2=A0|<= /span>=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--f403045e1ff23a5f41055ba89c6d-- From nobody Mon Oct 16 10:06:53 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 84CC5132D89; Mon, 16 Oct 2017 10:06:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , wes@mti-systems.com, aqm-chairs@ietf.org, draft-ietf-aqm-codel@ietf.org, ietf@kuehlewind.net, aqm@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <150817360649.352.11724755857107959402.idtracker@ietfa.amsl.com> Date: Mon, 16 Oct 2017 10:06:46 -0700 Archived-At: Subject: [aqm] Document Action: 'Controlled Delay Active Queue Management' to Experimental RFC (draft-ietf-aqm-codel-10.txt) 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: Mon, 16 Oct 2017 17:06:46 -0000 The IESG has approved the following document: - 'Controlled Delay Active Queue Management' (draft-ietf-aqm-codel-10.txt) as Experimental RFC This document is the product of the Active Queue Management and Packet Scheduling Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ Technical Summary This document describes a general framework called CoDel (Controlled Delay) that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. CoDel comprises some major technical innovations and has been made available as open source so that the framework can be applied by the community to a range of problems. It has been implemented in Linux (and available in the Linux distribution) and deployed in some networks at the consumer edge. In addition, the framework has been successfully applied in other ways. Working Group Summary CoDel was developed prior to the formation of the AQM working group. It was widely felt to be a good part of the answer to the "bufferbloat" problem that the IETF was trying to figure out how to deal with. The authors brought the specification of the algorithm to the working group after it was formed, and some clarifications and improvements to the description resulted from working group feedback. Document Quality There are multiple existing implementations, in simulators (e.g. ns-2, ns-3) and real operating systems (e.g. Linux, FreeBSD). The quality of the document is high in terms of being able to write new implementations, as it contains significant amounts of pseudo-code to describe the algorithm, along with textual descriptions of its design facets. Personnel Wesley Eddy (wes@mti-systems.com) is the document shepherd. Mirja Kühlewind is the AD. From nobody Mon Oct 16 12:55:18 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 D9B4A132939; Mon, 16 Oct 2017 12:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zGCApzmPY6Fd; Mon, 16 Oct 2017 12:55:15 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5407A132331; Mon, 16 Oct 2017 12:55:15 -0700 (PDT) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0: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 65B7C21425; Mon, 16 Oct 2017 19:55:11 +0000 (UTC) From: Dave Taht To: Andrew Mcgregor Cc: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= , Kathleen Nichols , "aqm-chairs\@ietf.org" , "Mirja Kuehlewind \(IETF\)" , Van Jacobson , Jana Iyengar , "aqm\@ietf.org" References: <727F4E15-6D92-4A56-AAC6-573652E98F67@kuehlewind.net> <1886F711-C7B1-415C-8F43-5691E54EDA51@kuehlewind.net> <87k1zva1al.fsf@toke.dk> Date: Mon, 16 Oct 2017 12:55:09 -0700 In-Reply-To: (Andrew Mcgregor's message of "Mon, 16 Oct 2017 22:50:16 +1100") Message-ID: <87r2u2rhpe.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] CoDel: After much ado ... 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: Mon, 16 Oct 2017 19:55:17 -0000 w00t! Andrew Mcgregor writes: > Win! > > On 16 October 2017 at 20:29, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > "Mirja Kuehlewind (IETF)" writes: >=20=20=20=20=20 > > Thanks! Will approve now! Finally! Yeah! >=20=20=20=20=20 > And there was much rejoicing! Wooh! :) >=20=20=20=20=20 > -Toke From nobody Mon Oct 16 16:24:09 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 1F85F132403; Mon, 16 Oct 2017 16:24:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" Cc: aqm@ietf.org, rs.ietf@gmx.at, wes@mti-systems.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <150819624212.21553.18116386062202973529.idtracker@ietfa.amsl.com> Date: Mon, 16 Oct 2017 16:24:02 -0700 Archived-At: Subject: [aqm] WG Action: Conclusion of Active Queue Management and Packet Scheduling (aqm) 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: Mon, 16 Oct 2017 23:24:02 -0000 The Active Queue Management and Packet Scheduling (aqm) working group in the Transport Area has concluded. The IESG contact persons are Spencer Dawkins and Mirja Kuehlewind. The working group has concluded their work. The mailing list will remain open for now to allow for further discussions on standardized and new AQM work. New work on AQM schemes that is intended for standardization in the IETF can be brought to the tsvwg group.