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 39A2521F867 for ; Fri, 7 Aug 2015 07:47:44 -0700 (PDT) Received: from pannekake.samfundet.no ([2001:67c:29f4::50] ident=unknown) by cassarossa.samfundet.no with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZNivu-0001S3-15; Fri, 07 Aug 2015 16:47:42 +0200 Received: from sesse by pannekake.samfundet.no with local (Exim 4.84) (envelope-from ) id 1ZNivt-0008Gj-Ra; Fri, 07 Aug 2015 16:47:41 +0200 Date: Fri, 7 Aug 2015 16:47:41 +0200 From: "Steinar H. Gunderson" To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Message-ID: <20150807144741.GB27438@sesse.net> References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com> <20150807142337.GA22258@sesse.net> <87r3nfqi97.fsf@toke.dk> <87mvy3qi23.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87mvy3qi23.fsf@toke.dk> X-Operating-System: Linux 4.2.0-rc5 on a x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) 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:48:13 -0000 On Fri, Aug 07, 2015 at 04:39:16PM +0200, Toke Høiland-Jørgensen wrote: > 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; Well, I already pointed out that DSCP doesn't really work :-) For one, the torrent client _isn't_ configured correctly. I have yet to actually see any setting DSCP bits in practice, although I'm sure they exist (e.g. I heard Dave was sending out patches). > 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. Yes, certainly. In a sense, the only reasonable solution I can see to this problem is to have two-level fq_codel (fair between senders, fair between flows for each sender), but that simply doesn't exist. Also you'd need to reverse it for downloads, and for someone in the middle, who knows what's actually up or down. /* Steinar */ -- Homepage: http://www.sesse.net/