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

Simon Barber <simon@superduper.net> Tue, 14 April 2015 16:20 UTC

Return-Path: <simon@superduper.net>
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 65D2B1B2E3A for <aqm@ietfa.amsl.com>; Tue, 14 Apr 2015 09:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.09
X-Spam-Level: *
X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 Hghp8sqsBVO5 for <aqm@ietfa.amsl.com>; Tue, 14 Apr 2015 09:20:25 -0700 (PDT)
Received: from masada.superduper.net (masada.superduper.net [85.119.82.91]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872A51B2E37 for <aqm@ietf.org>; Tue, 14 Apr 2015 09:20:25 -0700 (PDT)
Received: from 199-116-72-167.public.monkeybrains.net ([199.116.72.167] helo=[192.168.0.12]) by masada.superduper.net with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:128) (Exim 4.80) (envelope-from <simon@superduper.net>) id 1Yi3ZK-0008Hb-Sp; Tue, 14 Apr 2015 17:20:17 +0100
From: Simon Barber <simon@superduper.net>
To: Toke Høiland-Jørgensen <toke@toke.dk>
Date: Tue, 14 Apr 2015 09:20:06 -0700
Message-ID: <14cb8baf738.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net>
In-Reply-To: <87a8yan1g8.fsf@toke.dk>
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> <87a8yan1g8.fsf@toke.dk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.0.19 (build: 2100846)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/3Z81L_RtfXdHodaduoDH915tXHg>
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:20:27 -0000

Indeed fq_codel will work very well for many home users - especially where 
the home user can be expected to be aware of apps that might be gaming the 
system. If multiple homes are sharing a link it might not always work so well.

To construct an example where fair queueing works poorly, place a flow that 
is trying to game the system (e.g. a download performed by a download 
accelerator, launching multiple TCP streams for the single download) next 
to a bunch of flows that are opaque (e.g. Several VoIP calls through a VPN).

Simon

Sent with AquaMail for Android
http://www.aqua-mail.com


On April 14, 2015 9:01:55 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> 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