From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 7 22:40:31 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF4461065672 for ; Wed, 7 Oct 2009 22:40:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id D30EB8FC0C for ; Wed, 7 Oct 2009 22:40:31 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C9DA6B98A1; Wed, 7 Oct 2009 15:40:31 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E54C12D6012; Wed, 7 Oct 2009 15:40:30 -0700 (PDT) Message-ID: <4ACD18E1.3040901@elischer.org> Date: Wed, 07 Oct 2009 15:40:33 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Guy Helmer References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> <4ACD04E5.50806@palisadesys.com> In-Reply-To: <4ACD04E5.50806@palisadesys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Joe R Subject: Re: Extension of dummynet/ipfw to support userspace packet classification X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:40:32 -0000 Guy Helmer wrote: > Joe R wrote: >> We at ironport have a requirement to do bandwidth management, but the >> traffic classification (and selection of bandwidth pipes) is done in >> userspace. The reason classification is done in userspace is because the >> traffic classifications are something like streaming audio traffic, video >> traffic, based on website categories etc. >> >> >> >> Our appliance is based on FreeBSD, and so we decided to look at >> dummynet to >> support our requirement. We could not use dummynet as such because it >> uses >> ipfw for packet classification, where packet classification (and pipe >> selection) is done in kernel based on tcp/ip parameters like IP and port. >> >> >> >> So we decided to extended dummynet/ipfw to support packet >> classification in >> userspace. >> >> Our idea is to extended socket structure to have a pipe number and have a >> setsockoption to associate the pipe number to a socket structure. Then >> have >> a new ipfw target (mappedpipe), which will pass the packet to dummynet >> (similar to pipe target) but with the pipe number in the socket >> structure if >> it is non-zero. >> >> >> >> I would like to know your comments on this proposal and if people are >> interested, I will be happy to submit a patch on this. >> >> > I think it would be a very useful capability to apply a dummynet pipe to > a stream. > > My thinking was that it would be nice to be able to build a dynamic > table of connections in ipfw and then ipfw could pass packets that > matched the dynamic connections list through a specified dummynet pipe. > I think that is different than your design, though -- as I understand > it, your design would apply dummynet to packets written to a socket. > > Guy What they want to do is what I was going to do before I "left" there .. which is to allow a userland process (e.g. proxy) classify the session using some un-named method , assign some session key to the socket that can be attached to the mbufs in some way as they are generated. an in-kernel flow control module (e.g. dummynet) could then be left to enforce the bandwidth usage by that session. When I originally laid this out I thought we'd need the following parts working to allow this to happen: * ioctl to add value to a new field in the socket. * a place to store a copy of the field in the mbuf, OR a way to reference the one in the socket. * a way to get such packets to the right dummynet pipe. e.g. a new ipfw rule type. * A frontend to set up the pipes (not our problem).