feature of `packet per second`
Chris H
bsd-lists at bsdforge.com
Thu May 8 17:10:42 UTC 2014
> 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<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
>> 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<sys/timeb.h> which is
>>> deprecated"
>>> [-Werror,-W#warnings]
>>> #warning "this file includes<sys/timeb.h> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>
More information about the freebsd-ipfw
mailing list