From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 862D4201253; Wed, 1 May 2013 21:59:05 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id fp12so159849lab.32 for ; Wed, 01 May 2013 21:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4xiIGa+6cLq6uGT6eJ9pKi1NjXPTptsdF27rh/Cfu+A=; b=uHFEyGUxO2Llz4LE932neCuwcpaHTt5RBvowwiCdWItoQ8OLXnnKi16CuyIBK0UPHM gvavnRSgXeHTmi0GzKegFfEP46Q7V5F46Zz7m8nYgwMxt77gzLaa8R6/XXKs86q86HJ1 jbJqG5e8qSYr7tnyuVB/ox4jKgiDeAWeAqdGBTBW85nmW+BXpjyXhUtZg1yZDCO2FgTi yuoFAzOx2XBp/RwwNOn+r6YJy79Uhlz1grbfkvRe7XF3KaHECxYEPVSeVt0lavZqUYfK mSjdfumZm+Cpb2/wOp3PNWQ9zMGY08U6mVUOL6QWUpwNz2V/RkxR4KXhQ28LDaVg65Yr ZB8Q== MIME-Version: 1.0 X-Received: by 10.112.133.137 with SMTP id pc9mr2015224lbb.74.1367470742564; Wed, 01 May 2013 21:59:02 -0700 (PDT) Received: by 10.112.131.71 with HTTP; Wed, 1 May 2013 21:59:02 -0700 (PDT) In-Reply-To: <5181CD56.9050501@superduper.net> References: <51817A6F.1080006@superduper.net> <86AA48E0-B5CD-4A94-AF2B-D75178E8C660@gmail.com> <5181CD56.9050501@superduper.net> Date: Thu, 2 May 2013 14:59:02 +1000 Message-ID: From: Andrew McGregor To: Simon Barber Content-Type: multipart/alternative; boundary=047d7b3439a4d9f8b704dbb5178e 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 04:59:06 -0000 --047d7b3439a4d9f8b704dbb5178e Content-Type: text/plain; charset=ISO-8859-1 It is quite reasonable for edge devices to not use SFQ but actual FQ with one queue per flow (and some reasonable garbage collection heuristic). Or to use a few thousand queues. Most of the time connection tracking will be enabled on an edge router anyway, so the device is paying that overhead already. May as well use it. On Thu, May 2, 2013 at 12:20 PM, Simon Barber wrote: > 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? >> > ______________________________**_________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/**listinfo/codel > --047d7b3439a4d9f8b704dbb5178e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It is quite reasonable for edge devices to not use SFQ but= actual FQ with one queue per flow (and some reasonable garbage collection = heuristic). =A0Or to use a few thousand queues.

Mo= st of the time connection tracking will be enabled on an edge router anyway= , so the device is paying that overhead already. =A0May as well use it.


On Thu,= May 2, 2013 at 12:20 PM, Simon Barber <simon@superduper.net> wrote:
Or one could use more queues in SFQ, so that= the chance of 2 streams sharing a queue is small. Even perhaps use a diffe= rent strategy than hashing to distribute traffic to queues, although whatev= er strategy is used needs to be resistant to DoS attacks. Or one could clas= sify the VoIP traffic and prioritise that. Another possibility is a heurist= ic 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, leadin= g to the high loss rates for whatever is hashed together with a VoIP flow t= hat does not reduce it's bandwidth.

One downside to SFQ really.

The only real solution, for the scenario where this happens, would be to so= mehow 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. =A0The = big unanswered question is then: can this realistically be done? =A0Does Bi= tTorrent traffic get marked as the bulk, low priority traffic it is, for ex= ample?
_______________________________________________
Codel mailing list
Codel@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/codel

--047d7b3439a4d9f8b704dbb5178e--