From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B47B521F18F; Wed, 1 May 2013 19:20:14 -0700 (PDT) Received: from 199-83-222-22.public.monkeybrains.net ([199.83.222.22] helo=[192.168.1.119]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UXj7x-00008U-S3; Thu, 02 May 2013 03:20:12 +0100 Message-ID: <5181CD56.9050501@superduper.net> Date: Wed, 01 May 2013 19:20:06 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jonathan Morton References: <51817A6F.1080006@superduper.net> <86AA48E0-B5CD-4A94-AF2B-D75178E8C660@gmail.com> In-Reply-To: <86AA48E0-B5CD-4A94-AF2B-D75178E8C660@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Codel] [Bloat] Latest codel, fq_codel, and pie sim study from cablelabs now available X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 02:20:15 -0000 Or one could use more queues in SFQ, so that the chance of 2 streams sharing a queue is small. Even perhaps use a different strategy than hashing to distribute traffic to queues, although whatever strategy is used needs to be resistant to DoS attacks. Or one could classify the VoIP traffic and prioritise that. Another possibility is a heuristic approach - don't mix long lived bulk data streams in the same bucket as others. Simon On Wed 01 May 2013 05:00:27 PM PDT, Jonathan Morton wrote: > > On 1 May, 2013, at 11:26 pm, Simon Barber wrote: > >> Interesting to note that sfq-codel's reaction to a non conforming flow is of course to start dropping more aggressively to make it conform, leading to the high loss rates for whatever is hashed together with a VoIP flow that does not reduce it's bandwidth. >> >> One downside to SFQ really. > > The only real solution, for the scenario where this happens, would be to somehow identify all the BitTorrent traffic and stuff it into a single bucket, where it has to compete on equal terms with the single VoIP flow. The big unanswered question is then: can this realistically be done? Does BitTorrent traffic get marked as the bulk, low priority traffic it is, for example?