Re: [aqm] CoDel: After much ado ...

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 16 October 2017 08:43 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D100C134493 for <aqm@ietfa.amsl.com>; 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 <aqm@ietfa.amsl.com>; 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 <aqm@ietf.org>; 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)" <ietf@kuehlewind.net>
In-Reply-To: <CAGD1bZYu1NFMZs3PErp83ZWO6TFHoT2Bj-bsNq_sPLsF3QEN4w@mail.gmail.com>
Date: Mon, 16 Oct 2017 10:42:54 +0200
Cc: aqm@ietf.org, "aqm-chairs@ietf.org" <aqm-chairs@ietf.org>, Van Jacobson <vanj@google.com>, Andrew McGregor <andrewmcgr@google.com>, Kathleen Nichols <nichols@pollere.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1886F711-C7B1-415C-8F43-5691E54EDA51@kuehlewind.net>
References: <CAGD1bZYxeFggM6HqrKgh07chGuj1ccGBTuxvAZ=gSVw_4murZg@mail.gmail.com> <E65E22D6-4264-4BB9-B0DC-26030AF54425@kuehlewind.net> <CAGD1bZZ+NwOyp6mrAV1cXSsTvjVZoB0115kSSoo-avuxohRDbA@mail.gmail.com> <727F4E15-6D92-4A56-AAC6-573652E98F67@kuehlewind.net> <CAGD1bZYu1NFMZs3PErp83ZWO6TFHoT2Bj-bsNq_sPLsF3QEN4w@mail.gmail.com>
To: Jana Iyengar <jri@google.com>
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: <https://mailarchive.ietf.org/arch/msg/aqm/M8rYFC4iwPXfyIDvQ84T1DrThds>
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." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Oct 2017 08:43:02 -0000

Thanks! Will approve now! Finally! Yeah!

> Am 14.10.2017 um 08:31 schrieb Jana Iyengar <jri@google.com>:
> 
> Hi Mirja,
> 
> I've posted -10 of the draft, see more below.
>  
> > 2) Did you see Alia’s 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.)
> 
> 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…?
> 
> 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?“
> > 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’t count them but only those packets that actually get dropped by CoDel directly, right?
> 
> However, I don’t think using normative language in the sentences you’ve added makes sense because, as you say, drop is the only thing you can do. I guess you’d 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.“
> 
> Or something similar…
> 
> 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