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

Jana Iyengar <> Sat, 14 October 2017 06:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A4C0132D22 for <>; Fri, 13 Oct 2017 23:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Mx_j7vRWK9A for <>; Fri, 13 Oct 2017 23:31:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38FDA124207 for <>; Fri, 13 Oct 2017 23:31:27 -0700 (PDT)
Received: by 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;; 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;; 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 with SMTP id c127mr2264302ybb.398.1507962686111; Fri, 13 Oct 2017 23:31:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 13 Oct 2017 23:31:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Jana Iyengar <>
Date: Fri, 13 Oct 2017 23:31:25 -0700
Message-ID: <>
To: "Mirja Kuehlewind (IETF)" <>
Cc:, "" <>, Van Jacobson <>, Andrew McGregor <>, Kathleen Nichols <>
Content-Type: multipart/alternative; boundary="001a113e96023e1beb055b7becff"
Archived-At: <>
Subject: Re: [aqm] CoDel: After much ado ...
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

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

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

Thanks all!
- jana