From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 17:01:27 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 1B132E53 for ; Mon, 12 May 2014 17:01:27 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC65B2A3A for ; Mon, 12 May 2014 17:01:26 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kq14so4818332pab.33 for ; Mon, 12 May 2014 10:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=NFqVRoVQS7MGSnEceUtGbX07n03ZAK4Q/4AEjVbzs4M=; b=V/yAc98OryX74CqlYQ3SkBfO5Xmb8OgZQaGnWdgmD+WVl63wh38dztBCqHiW9MdHPH hhZHytHJJPokgTfD4LpugXLcwpyk7Mwc+cL6PEUiTsQm303is55+ZFky1Fqbt6pBjtpK 6SXkMszxHzN3K2i7gs+7Vck5gKBRD20QQWLq5oGb86IDdSZRQnrkAQW28EnwfSA9k2CQ gtRxkQ6KktsxCEbvPaaAvdQfxSXQcWBeEpvAKPmoSFnplmkDhRi3mBCfYiRRXI/mMTsc //VSUCqmbEBebt3BUL541bvDq0pZnPgq8y6JlqjFFVquqroEdQlu/wMhpH/QwMVwIX76 mSoA== X-Received: by 10.66.146.170 with SMTP id td10mr57740219pab.105.1399914086340; Mon, 12 May 2014 10:01:26 -0700 (PDT) Received: from [192.168.1.101] ([203.117.37.212]) by mx.google.com with ESMTPSA id gu1sm23809146pbd.0.2014.05.12.10.01.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 10:01:24 -0700 (PDT) Message-ID: <5370FE5E.3000104@gmail.com> Date: Tue, 13 May 2014 01:01:18 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: feature of `packet per second` 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> In-Reply-To: <536BACA4.7010702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-ipfw@freebsd.org" , Freddie Cash 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: Mon, 12 May 2014 17:01:27 -0000 On 5/9/14 0:11, bycn82 wrote: > 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 > pps _limit duration_ > Rule with the pps keyword will allow the first _limit > _packets in > each _duration _milliseconds. > > is that OK? Done ,submitted. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/189721