From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 17:10:41 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E35DCF9A for ; Thu, 8 May 2014 17:10:41 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 758C6A4D for ; Thu, 8 May 2014 17:10:40 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s48HBxOp057953; Thu, 8 May 2014 10:12:05 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s48HBsOI057950; Thu, 8 May 2014 10:11:54 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 8 May 2014 10:11:54 -0700 (PDT) Message-ID: <90ff4a7ff9a1d1bac510bb04fc457a91.authenticated@ultimatedns.net> In-Reply-To: <536BACA4.7010702@gmail.com> References: <5360F1F4.9060808@gmail.com> <5361105C.1040203@freebsd.org> <53611738.8010103@gmail.com> <53611EB1.4000406@gmail.com> <5364E097.9020106@gmail.com> <536AD13B.6080907@gmail.com> <536AD941.9090102@gmail.com> <20140508073816.GB64368@onelab2.iet.unipi.it> <536BACA4.7010702@gmail.com> Date: Thu, 8 May 2014 10:11:54 -0700 (PDT) Subject: Re: feature of `packet per second` From: "Chris H" To: "bycn82" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:10:42 -0000 > On 5/8/14 15:38, Luigi Rizzo wrote: >> On Thu, May 08, 2014 at 09:09:21AM +0800, bycn82 wrote: >>> On 5/8/14 8:35, bycn82 wrote: >>>> On 5/4/14 1:19, Luigi Rizzo wrote: >>>>> >>>>> >>>>> On Sat, May 3, 2014 at 2:27 PM, bycn82>>>> > wrote: >>>>> >>>>> On 5/2/14 16:59, Luigi Rizzo wrote: >>>>>> >>>>>> >>>>>> On Wed, Apr 30, 2014 at 6:02 PM, bycn82>>>>> > wrote: >>>>>> >>>>>> >>>>>> fjwcash@gmail.com >>>>>> > >>>>>> >>>>>> Thanks for your reply, and it is good to know the sysctl >>>>>> for ICMP. >>>>>> >>>>>> finally it works.I just added a new `action` in firewall and >>>>>> it is called `pps`, that means it can be generic purpose >>>>>> while the net.inet.icmp.icmplim is only for ICMP traffic. >>>>>> >>>>>> the usage will be like below >>>>>> >>>>>> root@F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from >>>>>> any to any* >>>>>> 00100 pps 1 icmp from any to any >>>>>> root@F10:/usr/src/sbin/ipfw # ./ipfw show >>>>>> 00100 9 540 pps 1 icmp from any to any >>>>>> 65535 13319 1958894 allow ip from any to any >>>>>> root@F10:/usr/src/sbin/ipfw # >>>>>> >>>>>> >>>>>> ???hi, >>>>>> as julian said it would be great if you would like to share your >>>>>> code >>>>>> so we can integrate it in future ipfw releases. >>>>>> Once again citing Julian, dummynet is a bit of a superset of pps but >>>>>> not exactly, so i see value in the additional feature. >>>>>> >>>>>> One thing ???to keep in mind in the implementation: >>>>>> >>>>>> the burst size used for limiting is an important parameter that >>>>>> everyone forgets. 1 pps is basically "don't bother me". >>>>>> 1000 pps could be "1000 packets every fixed 1-sec interval" >>>>>> or "1 packet every ms" or (this is more difficult) >>>>>> "20 pkt in the last 50ms interval". >>>>>> >>>>>> If i were to implement the feature i would add two parameters >>>>>> (burst, I_max) with reasonable defaults and compute the internal >>>>>> interval and max_count as follows >>>>>> if (burst> max_pps * I_max) >>>>>> burst = max_pps * I_max; // make sure it is not too large >>>>>> else if (burst< max_pps / HZ) >>>>>> burst = max_pps * HZ; // nor too small >>>>>> max_count = max_pps / burst; >>>>>> interval = HZ * burst / max_pps; >>>>>> count = 0; // actual counter >>>>>> >>>>>> then add { max_count, interval, timestamp, count } to the rule >>>>>> descriptor. >>>>>> On incoming packets: >>>>>> >>>>>> if (ticks>= r->interval + r->timestamp) { >>>>>> r->timestamp = r->ticks; >>>>>> r->count = 1; >>>>>> return ACCEPT; >>>>>> } >>>>>> if (r->count> r->max_count) >>>>>> return DENY; >>>>>> r->count++; >>>>>> return ACCEPT; >>>>>> >>>>>> cheers >>>>>> luigi >>>>>> >>>>> Hi Luigi, >>>>> You are right, it will be more generic if provide two parameters >>>>> as you described, >>>>> But this PPS feature should not be used to control the traffic >>>>> rate, the dummynet you provided is the correct way. >>>>> So I am thinking in what kind of scenario, people need this PPS >>>>> feature? >>>>> in my opinion, people will use PPS only when they want to limit >>>>> the connections/transactions numbers. ( already have limit >>>>> command to limit the connections) >>>>> So I think provide a simple PPS feature is good enough, and we >>>>> can improve it if someone complaint on this. >>>>> >>>>> >>>>> ???pps has a strong reason to exist because it is a lot cheaper >>>>> than a dummynet pipe, and given its pur???pose is to police >>>>> traffic (icmp, dns requests, etc) which should not even >>>>> get close to the limit which is set, I think it is >>>>> a completely reasonable feature to have. >>>>> >>>>> Given that the above code is the complete implementation >>>>> with the two parameters (burst and interval) there is no >>>>> reason not to use them, at least internally. >>>>> >>>>> Then you could choose not to expose them as part of the >>>>> user interface (though since you are implementing a new >>>>> option from scratch, it is completely trivial to >>>>> parse 1, 2 or 3 arguments and set defaults for the others). >>>>> >>>>> cheers >>>>> luigi >>>> OK, PPS with 2 parameters , it is done, >>>> But how to get the current time in millisecond? >>>> any recommendation? >>> In order to get the millisecond, i tried to include the timeb.h but i >>> met below >> FreeBSD has a global kernel variable called ticks which increments >> (roughly) HZ times per second and is all you need for this >> kind of coarse estimates. >> In linux there is something similar (jiffies maybe ?), >> and the code to build ipfw on linux does some reasonable >> mapping. >> >> The code i posted is, i believe, complete and contains >> all the details. >> >> cheers >> luigi >> >>> n file included from >>> /usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42: >>> @/sys/timeb.h:42:2: error: "this file includes which is >>> deprecated" >>> [-Werror,-W#warnings] >>> #warning "this file includes which is deprecated" >>> ^ >>> any replacement for timeb.h > > Man page patch for PPS > > .It Cm pps Ar limit duration > Rule with the > .Cm pps > keyword will allow the first > .Ar limit > packets in each > .Ar duration > milliseconds. > >- and it will be like blow + and it will be below > pps _limit duration_ > Rule with the pps keyword will allow the first _limit > _packets in > each _duration _milliseconds. > > is that OK? Just a suggestion. :) --Chris > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >