From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 10:03:10 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20AA7185 for ; Fri, 12 Dec 2014 10:03:10 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id C95BDEE3 for ; Fri, 12 Dec 2014 10:03:09 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id AAA00622 for ; Fri, 12 Dec 2014 00:11:23 -0700 (MST) Message-Id: <201412120711.AAA00622@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Dec 2014 00:10:31 -0700 To: net@freebsd.org From: Brett Glass Subject: Can DUMMYNET handle weighting of traffic according to firewall rules? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:03:10 -0000 Everyone: I have an interesting problem that I'm trying to solve with FreeBSD's IPFW and DUMMYNET facilities. I have an application in which, due to arbitration overhead, a half duplex data link has significantly higher costs -- typically about twice as much -- in one direction than in the other. I'd therefore like to set up a DUMMYNET pipe in FreeBSD that limits bandwidth usage so that 2*(bandwidth in one direction) + (bandwidth in the other direction <= total bandwidth limit It's easy to set IPFW up to sort the packets by direction, but it does not seem possible to inject them into the same pipe in such a way that some packets will count more toward the pipe's bandwidth limit than others. Any ideas on how I can implement this? Willing to code if I must, but don't want to reinvent the wheel. --Brett Glass