Re: [aqm] References on AQM test results and fq_nocodel

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 14 April 2015 16:04 UTC

Return-Path: <toke@toke.dk>
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 F41731B2DE4 for <aqm@ietfa.amsl.com>; Tue, 14 Apr 2015 09:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.206
X-Spam-Level: *
X-Spam-Status: No, score=1.206 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, 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 EAPEHhzK-gX2 for <aqm@ietfa.amsl.com>; Tue, 14 Apr 2015 09:04:19 -0700 (PDT)
Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (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 67D161B2E09 for <aqm@ietf.org>; Tue, 14 Apr 2015 09:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at mail2.tohojo.dk
Sender: toke@toke.dk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1429027304; bh=ayZf254jrlI+0SAFETJ+ZenpueP8dIX0UIh0nIqfmQg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=oFK9rXFjnN9teqS+f48vh3xp1zJjA6ZnckzxIO4YM30nFfSEbetEXrdVGjGoaHUKd m60wI1FWm5kaG9KR3YIrTfG9uApz9vRN3HNm+4GmN05m5rFc+7k+cdXpN6/8Uzo/jA MQSHkxMBH4O4Jzd0fLHn2xCu8+uK+S1LhP7MMeMw=
Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id D05E231ACAF; Tue, 14 Apr 2015 18:01:43 +0200 (CEST)
From: Toke Høiland-Jørgensen <toke@toke.dk>
To: Simon Barber <simon@superduper.net>
References: <1BFAC0A1D7955144A2444E902CB628F85E092996@US70TWXCHMBA11.zam.alcatel-lucent.com> <87vbh010tn.fsf@toke.dk> <1BFAC0A1D7955144A2444E902CB628F85E093A39@US70TWXCHMBA11.zam.alcatel-lucent.com> <87r3rolydh.fsf@toke.dk> <14cb8934af8.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net>
Date: Tue, 14 Apr 2015 18:01:43 +0200
In-Reply-To: <14cb8934af8.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> (Simon Barber's message of "Tue, 14 Apr 2015 08:36:45 -0700")
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87a8yan1g8.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/XkNqW1xisa7UcOrSZfgFa18K_6U>
Cc: Michael Welzl <michawe@ifi.uio.no>, aqm@ietf.org, "Francini, Andrea (Andrea)" <andrea.francini@alcatel-lucent.com>
Subject: Re: [aqm] References on AQM test results and fq_nocodel
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, 14 Apr 2015 16:04:23 -0000

Simon Barber <simon@superduper.net> writes:

> One problem with fair queueing is that it can be gamed. By opening
> multiple flows you achieve unfair priority. Part of Codel or PIE's
> beauty is that they are blind to the traffic, only reacting to the
> externally visible characteristics. This stems from the question 'what
> is a flow?'. There is no easy answer to this question, so Codel and
> PIE intentionally avoid the question.

Sure, if we knew what the One True Queue Management Scheme that always
did the right thing was, we probably wouldn't be having this
conversation. :)

> Of course in many practical situations some simple assumptions about
> what a flow is do work, and in those situations fair queueing performs
> very well. It's important to keep in mind the limitations though. Fair
> queueing is not a panacea.

Well, my focus has primarily been "why does my internet suck so much and
what can I do to fix it". And for that (e.g. home type networks)
fq_codel is very close to a panacea.

I am well aware that there probably exists situations in which the
fq_codel assumptions do not hold up (and we do point out a couple in the
draft). However, I don't think I've ever seen someone actually
*demonstrate* (you know, with data) a scenario where fq_codel performs
worse than either Codel or PIE. If someone can point me to such a
demonstration I'll be happy to be proved wrong... :)

-Toke