From owner-freebsd-net@FreeBSD.ORG Wed May 9 19:23:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47BFE106564A for ; Wed, 9 May 2012 19:23:19 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C5C978FC0A for ; Wed, 9 May 2012 19:23:18 +0000 (UTC) Received: by bkvi17 with SMTP id i17so816191bkv.13 for ; Wed, 09 May 2012 12:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1qs2uS0iArVg9iwV/Lp606aZGJO2mUkQ7RvXoxQWyII=; b=ULLxSqkwSSgGG7TLYTKrDrac8mRetKXItkKd5nF/KbITrzOZVuZEtN2y5rK3t6e66n hWtTAn3hSBJDaeDH+hOjgddat5glZtuZo7YVaE9Nyqfwba0f2JgmsXpo38aTdJyazFw/ qOnXt0UsotPgwE77P+t7/z/DI1hkG6R4y52Z7n24OqwsVzb1fX/RDGF6gCdXuuiQc0Eq dkHLd3xUgDs9ma6C3mOR+KMXKAEQxghou5y85vzVXmfCoYAsqlYLbA90PWiFRzVmTbxk nXgAtpEAj8z3L7XFRgstSISpOp5ycsOXgIoutzn4OQXs4ZlwzUIZED5g2dswqzKv95b+ 2NfQ== MIME-Version: 1.0 Received: by 10.204.9.216 with SMTP id m24mr494979bkm.67.1336591397425; Wed, 09 May 2012 12:23:17 -0700 (PDT) Received: by 10.204.133.212 with HTTP; Wed, 9 May 2012 12:23:17 -0700 (PDT) Date: Wed, 9 May 2012 15:23:17 -0400 Message-ID: From: Zaphod Beeblebrox To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Subject: Adding CoDel to the stack. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 19:23:19 -0000 I was wondering if anyone had considered adding "CoDel" to the queuing infrastructure in FreeBSD. The ACM paper on it is http://queue.acm.org/detail.cfm?id=2209336 . The "short" of it is that current TCP behaviour encourages router/switch buffers to always be "full" and that other solutions like RED (Random Early Drop) are difficult to configure properly and thus disfavoured. This new solution uses completely different factors to determine what to drop ... and in doing so is a zero-config solution ---- only needing to know the speed of the link.