[aqm] Review of draft-hoeiland-joergensen-aqm-fq-codel-00
Jim Gettys <jg@freedesktop.org> Tue, 30 September 2014 21:24 UTC
Return-Path: <gettysjim@gmail.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ACF1A9174 for <aqm@ietfa.amsl.com>; Tue, 30 Sep 2014 14:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.922
X-Spam-Level:
X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 MX50Lzy1RQuD for <aqm@ietfa.amsl.com>; Tue, 30 Sep 2014 14:24:17 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0411A897A for <aqm@ietf.org>; Tue, 30 Sep 2014 14:24:15 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id em10so4761206wid.1 for <aqm@ietf.org>; Tue, 30 Sep 2014 14:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=84vNnDUzkxyjuR18WbF2/riyg7N5yUH0aDWQXgFzVA4=; b=jDFtnYhtM9qhVwEZWdD6He0IXDj2yzUtb5rBjs/t4FWvY+Bj06LnUNimBWuIFhRo4z ml7GZE7a7oL8fsynWXAy/zncCWJKyUkv33c0Vwxk2UC43JqgUVi3Zn9vRPaOAwr6eLfs imGcb+Epw1ld7DKjANjzICpAk5LzHXiDaS5lAv3U64/CLi7/MuroBPDpBOiE9+Hk+0l+ /ohfnOsvIDw7JZlN7flRBCmP/+tUyanfT8cACsfluEgoz7+bWZAyE2D9vBSkXeb1RWjU RMN+mrHssLsOxVqzkjdUjo8Pox087nIUNdqhec8qHfpscu5BS4ovXmX6roEXW329FYLg hUIQ==
MIME-Version: 1.0
X-Received: by 10.194.78.76 with SMTP id z12mr33018449wjw.24.1412112254176; Tue, 30 Sep 2014 14:24:14 -0700 (PDT)
Sender: gettysjim@gmail.com
Received: by 10.194.107.197 with HTTP; Tue, 30 Sep 2014 14:24:13 -0700 (PDT)
Date: Tue, 30 Sep 2014 14:24:13 -0700
X-Google-Sender-Auth: LN6-OJTWYBBWwdE3difLJHXN9Go
Message-ID: <CAGhGL2AHJZGm9=9zm9iAZDSPyX4NpMGfYMdjmw4SKrzyvbqKFA@mail.gmail.com>
From: Jim Gettys <jg@freedesktop.org>
To: Toke Høiland-Jørgensen <toke@toke.dk>
Content-Type: multipart/alternative; boundary="047d7bf0d80a4b13d105044f0143"
Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/8EO17u2b8rgys8RlQY44EwwN5aI
Cc: "aqm@ietf.org" <aqm@ietf.org>
Subject: [aqm] Review of draft-hoeiland-joergensen-aqm-fq-codel-00
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 30 Sep 2014 21:24:19 -0000
Looks pretty good to me. I took a pretty good read on the airplane west yesterday, and comments are below. - Jim 1. "The rest of this document" is immediately followed by "The rest of this section". That repetition is unfortunate, and the second is capitalized. 1.2 You should note again that fq_codel is not limited to hashing on f-tuples; just that the current implementation defaults to hashing those. Noting that fq_codel gets really good performance is nice and usually better than most deployed ad-hoc classification schemes, but you should also note that if you want hard "guarantees" of performance, packet classification still has a role to play. For example, multiplexing a control plane for a network over that network would be something that requires explicit classification to provide such guarantees. 4.1.2 Target Should the target be tuned to at least the transmission time of an aggregate on aggregating media (e.g. Cable, 802.11n, etc)? I think so.... but we can/should check with Kathy and Van.... 4.1.3 This default of 10240 packets bothers me. That's of order 15,306,000 bytes. It should be computed on link speed, or maybe observed transmission rate. And should it be in bytes? How does one compute the "suitable size"? So it's wrong by at least an order of magnitude for *most* current devices. We really don't want to discourage naive people on IoT devices to think that it will eat them out of house and home and therefore not to use fq_codel. At a minimum, we should note that this is an artifact of the current implementation, and note the shortcoming of the current implementation. Sigh. Where did our "no knobs" mantra get lost? I guess Eric is too used to machines with 10G and faster ethernet interfaces. 5.3 The "Jenkins" hash should be referenced. Which one is used? Possibly worth noting that some other hash could also be used (I presume it can be?), and why was the Jenkins hash chosen? 5.2 "This is because otherwise the queue can" -> "Otherwise the queue could" The last paragraph does probability computations; IIRC, this was work done by Paul McKenney for SFQ. It should be referenced. 6.2 There are indenting problems in this section. 6.3 "it cannot be easily retrofitted to devices". Cannot is a bit strong; some silicon may also have modifyable firmware. I'd say instead: "it may be impossible to retrofit devices that do most of their processing in silicon and lack space for timestamping" You say: Also, timestamping functions in the core OS need to be very efficient. Somehow we should make clear that perfection is not required. Timestamping to of order a millisecond is fine; certainly getting time at that resolution is sufficient, so long as the overhead to get the time at that resolution is very low. 6.5 You say: Finally, FQ-CoDel drops packets from the largest flows sooner and more accurately than CoDel alone, and it is more responsive to changes in bandwidth, and in number of flows, than CoDel alone. Why is this true? It's an assertion without explanation. I'd be happier if there is a one/two sentence explanation.
- [aqm] Review of draft-hoeiland-joergensen-aqm-fq-… Jim Gettys
- Re: [aqm] Review of draft-hoeiland-joergensen-aqm… Dave Taht
- Re: [aqm] Review of draft-hoeiland-joergensen-aqm… David Collier-Brown