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

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 14 April 2015 15:57 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 5AE111B2D45 for <aqm@ietfa.amsl.com>; Tue, 14 Apr 2015 08:57:23 -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 61oF-R2lwUYF for <aqm@ietfa.amsl.com>; Tue, 14 Apr 2015 08:57:22 -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 CB3681B2D7E for <aqm@ietf.org>; Tue, 14 Apr 2015 08:57:21 -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=1429027033; bh=L0CkdFf6OJbTIJKTvox/iv/nj4LTZyij+ZnQGTUI28I=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Y4SmcdvTsAS9tJJOfMGUeiwTYItvcWS9yG8FpKQePnWkHAwlK7LOlniBNxe2/WFZg VSi+8xR5lchqNCBdNWLGZkkhpNmqlH4aNwqTXsyw4u/wCE6FOl/djBhooxGKXDcEHH jdsL721vre40SXmUASU6w4ddfm39geotciV5YXkk=
Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id F183631AC9F; Tue, 14 Apr 2015 17:57:12 +0200 (CEST)
From: Toke Høiland-Jørgensen <toke@toke.dk>
To: "De Schepper, Koen (Koen)" <koen.de_schepper@alcatel-lucent.com>
References: <1BFAC0A1D7955144A2444E902CB628F85E092996@US70TWXCHMBA11.zam.alcatel-lucent.com> <87vbh010tn.fsf@toke.dk> <1BFAC0A1D7955144A2444E902CB628F85E093A39@US70TWXCHMBA11.zam.alcatel-lucent.com> <87r3rolydh.fsf@toke.dk> <CAGhGL2Cn4CyBe0ZpKK6Mfca-bHnYmSC3BaTx5FZX5=hD5qhGVw@mail.gmail.com> <BF6B00CC65FD2D45A326E74492B2C19FB75C1ED6@FR711WXCHMBA05.zeu.alcatel-lucent.com>
Date: Tue, 14 Apr 2015 17:57:12 +0200
In-Reply-To: <BF6B00CC65FD2D45A326E74492B2C19FB75C1ED6@FR711WXCHMBA05.zeu.alcatel-lucent.com> (De Schepper's message of "Tue, 14 Apr 2015 15:39:56 +0000")
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87egnmn1nr.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/i5e2K_k_Mj9XdmfU_w70m2Dr8Ow>
Cc: "Francini, Andrea (Andrea)" <andrea.francini@alcatel-lucent.com>, Jim Gettys <jg@freedesktop.org>, Michael Welzl <michawe@ifi.uio.no>, "aqm@ietf.org" <aqm@ietf.org>
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 15:57:23 -0000

"De Schepper, Koen (Koen)" <koen.de_schepper@alcatel-lucent.com> writes:

> Reporting the self inflicted delay on greedy flows might be a good
> measurement to additionally report in the test suites, so its impact
> on greedy interactive applications can be estimated.

Some sort of greedy real-time media or equivalent is definitely missing
from my suite of tests. However, that is partly due to the lack of a
good tool to do it with; preferably one that actually matches real
deployed applications (webrtc for instance), and that doesn't require
either synchronised clocks, packet dumps, or inspecting the router
queues while running.

On the page I linked to there are packet dumps available from my tests,
btw, in case anyone does want to go extract some of these figures from
them...

> I expect also that the advantage of FQ in general will becomes less
> relevant if the queue of all flows in the network are very small and
> even most of the time empty. This is what you see already when a low
> latency configured AQM is combined with FQ. The lower the latency in
> the queues the less the impact of FQ. FQ might still have an advantage
> in case of dynamics where a queue build up cannot be avoided.

Well, I haven't yet seen an AQM that can keep the queue "very small and
even most of the time empty" in the presence of (e.g.) the RRUL test.
Especially not during the period where the flows start up (or, roughly
equivalent, if the bandwidth changes very rapidly). FQ helps a lot here,
especially for the transients.

-Toke