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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id D5A9821FDBD for ; Fri, 7 Aug 2015 07:39:26 -0700 (PDT) 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=1438958358; bh=G+1FK5YmpfukkgbOfj57Tu9YBABpi2Hq034IhdkRxVk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=ZBbjkr7LUnSkcSaveYGZDj6fIbk2OcPLY4AnqCSy5QopfZHxsHQaTCcBxP9kBRcW2 ApWAyOwLtBlpBb/ZbaVctEnRuOuU0oEjIWQtVzUZUC7N/jbPOPMmRoIkhiRsa2KSNp oH9X2TKkXSZmfqlSR0DvuqXzNLRi15LJXRB3Injs= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id DC7F442B08; Fri, 7 Aug 2015 16:39:16 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Mikael Abrahamsson References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com> <20150807142337.GA22258@sesse.net> <87r3nfqi97.fsf@toke.dk> Date: Fri, 07 Aug 2015 16:39:16 +0200 In-Reply-To: <87r3nfqi97.fsf@toke.dk> ("Toke =?utf-8?Q?H=C3=B8iland-J?= =?utf-8?Q?=C3=B8rgensen=22's?= message of "Fri, 07 Aug 2015 16:35:00 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87mvy3qi23.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Fwd: Did *bufferbloat* cause the 2010 flashcrash? 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: Fri, 07 Aug 2015 14:39:55 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: >>> [1] For the purposes of the question, the =E2=80=9CBitTorrent problem= =E2=80=9D is when you and >>> I are on the same network, and your 200+ BitTorrent upload sessions mak= es it >>> impossible for me to upload my single cat video to YouTube. >> >> Isn't this dependent on the upload speed? I would imagine that if it's 5= -10 >> megabit/s, then using Codel or similar technique that doesn't allow the = buffer >> to grow to hundreds of milliseconds, would improve things a lot? >> >> For a 500 kilobit/s link, I'm not sure even that would work...? > > There are two separate issues:=20 (three if you count me hitting send too soon...) 1. When you turn on bittorrent, everything becomes unbearably slow because you have huge amounts of bloat. I.e. web browsing doesn't work, your voice calls drop, etc. fq_codel solves this pretty nicely (I don't even notice when bittorent is on anymore). 2. Bandwidth sharing between bittorrent and other protocols. Bittorrent uses utp to try to be a scavenger that will back off and not use bandwidth if other traffic needs it. fq_codel breaks this by isolating flows and taking away the signal utp uses to back off. Diffserv with a suitable scheduler (cake, for instance) can fix this if the bittorrent client is configured correctly; or you could use deep(er) packet inspection to try to figure out which traffic is bittorent. But we don't have a shrinkwrap solution to this presently, AFAIK. I believe the cat video upload falls into category 2. -Toke