From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 8ACDC21F300 for ; Wed, 25 Feb 2015 11:30:17 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YQhev-0001tU-4O; Wed, 25 Feb 2015 20:30:13 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YQheu-0002ry-K3; Wed, 25 Feb 2015 20:30:13 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Wed, 25 Feb 2015 20:30:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <00EB8A35-6073-44DD-9C8E-0E875BD2B5E6@ifi.uio.no> 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> To: David Lang X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 25998 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D5254D1B0C804AA9F1387EB2763665723DAE26CC X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 349 max/h 13 blacklist 0 greylist 0 ratelimit 0 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 19:30:46 -0000 > On 25. feb. 2015, at 20.04, David Lang wrote: >=20 > On Wed, 25 Feb 2015, Michael Welzl wrote: >=20 >> 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. >=20 > If you only have one flow, then FQ should be just fine as you aren't = competing against anything. >=20 > When your one flow starts mixing with other people's traffic, you will = suffer a bit if they use multiple flows, this is of course the situation I meant - > but how could anything possibly tell that you are doing many things = through that one flow rather than doing a single massive thing that = should be limited for fairness with others? >=20 > The areas of the network that could have this knowledge don't have the = competing flows, by the time you get to the point where you do have = competing flows, you don't have any way of getting the knowledge (you = can't trust whatever the user tells you as they could be just gaming you = to get an unfair share of bandwidth) Not enforcing anything will let things play out like before. FQ is the = opposite end, by enforcing per-flow fairness. I'm not saying one is = better than the other, but recently, quite often I hear that yes, FQ is = always better :-) Not always clear and worth investigating is all I say. Cheers, Michael