From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2D6B321F226 for ; Wed, 25 Feb 2015 03:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 3EB473E35E5; Wed, 25 Feb 2015 12:24:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1424863460; bh=hCWvbTbCA3UtIVnoLG+R83w2OOAcjcrvVRSxta/b16Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=FLjkQoA1BUHJM6Y0eKTe6VO8cjXxtj2hUdyPtnVkxXa467KiiiLCB09N3N3/vOtfn XFfVMT8LBnZtC2ZlcUxtgKzPKT8XbSwZT1iL1bUZJR2EZNiXxauKX113V2FJR6p3Jk MVtif2XJu+qjiQsU24Rl37Z0ILo7UVHMdUuoQRxQ= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Michael Welzl References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> <4A80D1F9-F4A1-4D14-AC75-958C5A2E8168@gmx.de> <3F47B274-B0E4-44F2-A434-E3C9F7D5D041@ifi.uio.no> <87twyaffv3.fsf@toke.dk> Date: Wed, 25 Feb 2015 12:24:19 +0100 In-Reply-To: (Michael Welzl's message of "Wed, 25 Feb 2015 10:54:48 +0000") Message-ID: <87k2z6fd3w.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Cc: Alex Elsayed , "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] RED against bufferbloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 11:24:56 -0000 Michael Welzl writes: > +1, certainly it has a big influence. This has been well known for > many years though, and documented broadly, perhaps most notably by Jim > Roberts. Being "well known for many years" in the academic community unfortunately doesn't translate into deployment. Which is why I think there should be a place for both approaches: the "let's simplify and get a thorough base understanding" and the "let's run this on real stuff and see what happens". > Here I disagree, for two reasons: > > 1) The AQM part kicks in per flow. So, whenever you have one flow, the > behavior of FQ_AQM and AQM will be the same. Investigating what an AQM > mechanism does to one flow is then worthwhile. > > 2) Not everyone will always want FQ everywhere. There are potential > disadvantanges (e.g. the often mentioned with-a-VPN-I'm-only-1-flow problem). > What's necessary is to quantify them - to see how the effect of FQ (or > FQ_CoDel's changed FQ) plays out, and you've done a great start there in my > opinion. I didn't mean that investigating AQM behaviour is not worthwhile, far from it. But I believe that FQ needs to play a much larger role than it does currently in solving the larger problem of network (latency) behaviour under load. And completely separating the two is academic; not in the derogatory sense (as in "a problem not worth discussing"), but in the literal sense (as in "the thing we do in academia"). -Toke