From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [IPv6:2001:67c:29f4::29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2615221F1D4 for ; Mon, 16 Dec 2013 06:50:43 -0800 (PST) Received: from pannekake.samfundet.no ([2001:67c:29f4::50] ident=unknown) by cassarossa.samfundet.no with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VsZVH-0003kj-Hu for bloat@lists.bufferbloat.net; Mon, 16 Dec 2013 15:50:39 +0100 Received: from sesse by pannekake.samfundet.no with local (Exim 4.80) (envelope-from ) id 1VsZVH-0007iD-53 for bloat@lists.bufferbloat.net; Mon, 16 Dec 2013 15:50:39 +0100 Date: Mon, 16 Dec 2013 15:50:39 +0100 From: "Steinar H. Gunderson" To: bloat@lists.bufferbloat.net Message-ID: <20131216145039.GA22991@sesse.net> References: <9660C545-473C-4039-AB42-A12B7C761FC8@cisco.com> <201312152257.rBFMveZO022075@bagheera.jungle.bt.co.uk> <80CEFF86-8687-4266-B87C-8FB5B894D4DF@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 3.12.5 on a x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Bloat] [e2e] [aqm] What is a good burst? -- AQM evaluation guidelines 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: Mon, 16 Dec 2013 14:50:44 -0000 On Mon, Dec 16, 2013 at 04:28:35PM +0200, Jonathan Morton wrote: > I am also reminded of the livestreamed demoscene event from a couple of > years ago, which was producing enormous aggregate bursts every time a frame > group completed encoding (multiple times a second). This wasn't enough on > a single flow to impact individual end-users much, but it overwhelmed the > local and gateway buffers chronically, thereby crippling the entire > livestreaming exercise until a workaround could be implemented. FWIW, as the person in charge of said livestreaming: Since last year we did pacing (with HTB hacks; for 2014, we'll use sch_fq with hand-set rate limits). It worked out much better. We're in a very simple situation, though, with only one possible quality per stream (no autotuning up/down, users will do that manually if they're not happy); I think there was a paper back where people had reverse-engineered the Netflix algorithm for changing bitrates, and that problem isn't trivial at all. /* Steinar */ -- Homepage: http://www.sesse.net/