feature of `packet per second`

bycn82 bycn82 at gmail.com
Thu May 8 01:09:27 UTC 2014


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 <bycn82 at gmail.com 
>> <mailto:bycn82 at gmail.com>> wrote:
>>
>>     On 5/2/14 16:59, Luigi Rizzo wrote:
>>>
>>>
>>>
>>>     On Wed, Apr 30, 2014 at 6:02 PM, bycn82 <bycn82 at gmail.com
>>>     <mailto:bycn82 at gmail.com>> wrote:
>>>
>>>
>>>             fjwcash at gmail.com <mailto:fjwcash at gmail.com>
>>>             <mailto:fjwcash at gmail.com <mailto:fjwcash at 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 at F10:/usr/src/sbin/ipfw # .*/ipfw add pps 1 icmp from
>>>         any to any*
>>>         00100 pps 1 icmp from any to any
>>>         root at 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 at 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

n file included from 
/usr/src/sys/modules/ipfw/../../netpfil/ipfw/ip_fw2.c:42:
@/sys/timeb.h:42:2: error: "this file includes <sys/timeb.h> which is 
deprecated"
       [-Werror,-W#warnings]
#warning "this file includes <sys/timeb.h> which is deprecated"
  ^
any replacement for timeb.h


More information about the freebsd-ipfw mailing list