From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by huchra.bufferbloat.net (Postfix) with ESMTP id 4419D21F129; Mon, 6 May 2013 10:54:46 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r46Hshaw022617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 May 2013 13:54:43 -0400 Received: from localhost (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r46Hse9q011287; Mon, 6 May 2013 13:54:42 -0400 Date: Mon, 6 May 2013 19:54:38 +0200 From: Jesper Dangaard Brouer To: Simon Barber Message-ID: <20130506195438.5df6d1cd@redhat.com> In-Reply-To: <5181CD56.9050501@superduper.net> References: <51817A6F.1080006@superduper.net> <86AA48E0-B5CD-4A94-AF2B-D75178E8C660@gmail.com> <5181CD56.9050501@superduper.net> Organization: Red Hat Inc. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Mailman-Approved-At: Mon, 06 May 2013 10:59:51 -0700 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: Mon, 06 May 2013 17:54:46 -0000 On Wed, 01 May 2013 19:20:06 -0700 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. The Linux implementation of fq_codel is actually doing a really nice trick to distinguish between new and old flows. Giving new flows precedence and avoiding they get exposed to a round-robin delay from all the old "bulk" data streams. A flow is considered "new" if no packets for the given flow exists in the queue. It does not have to be a truly new-flow, it just have to send packets "slow"/paced enough, that the queue is empty when the next packet arrive. Perhaps VoIP would fit this traffic profile, and thus would work better with the Linux fq_codel implementation, compared to the SFQ-Codel used in the simulation. Looking at the implementation, it does have the problem that the match for "if the flow already have packets in the queue" just looks to see if the hash bucket is empty. Thus 2 stream sharing a hash queue throw this off. -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer