From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 8751421F322 for ; Wed, 25 Feb 2015 11:04:52 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t1PJ4fHX030688; Wed, 25 Feb 2015 11:04:42 -0800 Date: Wed, 25 Feb 2015 11:04:41 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Michael Welzl In-Reply-To: Message-ID: 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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:05:20 -0000 On Wed, 25 Feb 2015, Michael Welzl wrote: > 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. If you only have one flow, then FQ should be just fine as you aren't competing against anything. When your one flow starts mixing with other people's traffic, you will suffer a bit if they use multiple flows, 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? 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) David Lang