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 D020C3CBB5 for ; Sun, 28 Feb 2016 16:27:24 -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=1456694843; bh=0GjBtUZu754jsZwFzef4+V0kMyef1dKC76R1CbckrzQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=OLfnNhW6uchKQEd1WRuEpsvUXlLhK4e2TIPj1pUsvezvx1+TZOmZjgS/xZSj1NbBg PzsLXvThX3TMDEI7jH7DN3jzsNnt8v015+SkLhTq61EWNXzQrp2ukwzvQy4GV6RGCP 5UwApeT2s/uzaRD3q3gBCeXcACgPaoatZe0u4yL4= Sender: toke@toke.dk Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 047EC62ED49; Sun, 28 Feb 2016 22:27:22 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Juliusz Chroboczek Cc: Alan Jenkins , bloat@lists.bufferbloat.net References: <56BB8F05.2030006@mti-systems.com> <56D1F349.6040601@taht.net> <87egbx54zf.fsf@toke.dk> <56D303A6.4050302@gmail.com> <87oab0d1sm.wl-jch@pps.univ-paris-diderot.fr> Date: Sun, 28 Feb 2016 22:27:21 +0100 In-Reply-To: <87oab0d1sm.wl-jch@pps.univ-paris-diderot.fr> (Juliusz Chroboczek's message of "Sun, 28 Feb 2016 21:20:57 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8760x85xvq.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 21:27:25 -0000 Juliusz Chroboczek writes: >>> 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... > > Perhaps I'm missing something -- how do you to pick the right rate for > a given user? Congestion control? With something like fairness queueing that keeps bandwidth very stable at the fair share, you could conceivably get away with a much shallower playback buffer in the application and stream at something very close to real time, rather than using the chunk-based retrieval of HAS. However, that remark was mostly meant to be tongue-in-cheek... not sure if there exists any really good congestion control algorithms for real-time video. -Toke