feature of `packet per second`
Bill Yuan
bycn82 at gmail.com
Fri May 9 03:00:58 UTC 2014
OK then I will submit it as a patch in this weekend.
On Fri, May 9, 2014 at 1:11 AM, Chris H <bsd-lists at bsdforge.com> 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<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