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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0A88F3CB95 for ; Sun, 28 Feb 2016 08:39:18 -0500 (EST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1456666757; bh=3Wotbcl8qpQPVq3bCM4FoykcF4xm468UGNcZ3cx27b4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=jFLUMh5swTIZ037WV28bHeCBa1S1a/8HTMhPCt7cg2w3hfA+gT1Mj+Jk9i3SdnQep c4e0dZPOwSnFd0rUM6kDvr2lOEJXNtmca+Jego7iQF/iNNYNFyJc+PHyaxjzUW5+N2 HK625MPv1421v0CMqncfFZ3ev8lONIUPZOpQo0oA= Sender: toke@toke.dk Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 55DBF62A41A; Sun, 28 Feb 2016 14:39:16 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Alan Jenkins Cc: Dave =?utf-8?Q?T=C3=A4ht?= , bloat@lists.bufferbloat.net References: <56BB8F05.2030006@mti-systems.com> <56D1F349.6040601@taht.net> Date: Sun, 28 Feb 2016 14:39:16 +0100 In-Reply-To: (Alan Jenkins's message of "Sun, 28 Feb 2016 13:33:38 +0000") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87egbx54zf.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bloat] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 13:39:19 -0000 Alan Jenkins writes: > I wouldn't complain that I can't sustain 2056Kbps goodput when my fair > share of the shaped bandwidth is 2000Kbps. The results might be > showing a significant degradation, or it could be a marginal one that > pushes over the boundary (between the 2056k and 1427k encodes). Which > of those conclusions you start from might be influenced by whether > you're developing a different AQM, hmm. Exactly. And note how they just so happen to pick 11 total flows (10 competing, one video) to share the bottleneck, putting the per-flow throughput just below the rate needed to go up one quality level. What a coincidence. At least it shows how difficult it is to design experiments that put fairness queueing in a bad light ;) Oh, and of course HAS is in itself a hack to work around badly managed queues in the network. In a nicely fairness queued world, we could do away with HAS entirely and just, y'know, stream things at the desired rate... -Toke