Date: Thu, 27 Sep 2001 11:27:35 +0100 (BST) From: =?iso-8859-1?q?Adam=20Nealis?= <adamnealis@yahoo.co.uk> To: Sheldon Hearn <sheldonh@starjuice.net>, Joseph Gleason <clash@zogbe.tasam.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Using ipfw pipes for bandwidth management - can it allow for "bursting"? Message-ID: <20010927102735.18568.qmail@web20708.mail.yahoo.com> In-Reply-To: <002901c146dc$de5ef8c0$095f5f0a@battleship>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Joseph Gleason <clash@tasam.com> wrote: > I didn't say the dummynet man page has all answers, but it is somewhere to > look. > > The only thing I can find is this from the ipfw page: Yep. I got that far. But on reading this there is no explanation of what the numbers mean, or rather, their context. > red | gred w_q/min_th/max_th/max_p > Make use of the RED queue management algorithm. w_q and max_p > are floating point numbers between 0 and 1 (0 not included), OK, so now I know that 0 < w_q, max_p <= 1.0 > while min_th and max_th are integer numbers specifying > thresholds > for queue management (thresholds are computed in bytes if the > queue has been defined in bytes, in slots otherwise). The > dummynet(4) also supports the gentle RED variant (gred). Three > sysctl(8) variables can be used to control the RED behaviour: > > net.inet.ip.dummynet.red_lookup_depth > specifies the accuracy in computing the average queue > when the link is idle (defaults to 256, must be greater > than zero) So this number must be >0, but what is tha maximum range, what does varying this mnumber affect? Same question applies to the next two sysctl parameters. > net.inet.ip.dummynet.red_avg_pkt_size > specifies the expected average packet size (defaults to > 512, must be greater than zero) > > net.inet.ip.dummynet.red_max_pkt_size > specifies the expected maximum packet size, only used > when queue thresholds are in bytes (defaults to 1500, > must be greater than zero). I suppose what I must do is to find papers describing RED and GRED, digest them and map the information onto the man pages. So I'll look at http://www.acm.org/crossroads/columns/connector/july2001.html as suggested by Aaron. I did come across some technical discussions of RED/GRED, but digesting that sort of information can take days so I thought I'd ask here first to see if it was a valid line of research. My reason for posting in the first place was to see if anyone had actually done any work with ipfw pipes (or dummynet directly), in order to allow for b/w management with bursting. By bursting I suppose I mean something like for a connection with nominal aggregate bandwidth X bit/s, make available additional bandwidth of either X * Y bit/s, or X + Y bit/s for a time Tb seconds. From what I gather this has not been done using ipfw. Is this because it can't in principle, because it hasn't been done yet, because there is somthing else to use, or because anyone who has done this didn't read the post (or read it and didn't respond)? ;) Cheers, Adam Nealis. > > > ----- Original Message ----- > From: "Sheldon Hearn" <sheldonh@starjuice.net> > To: "Joseph Gleason" <clash@zogbe.tasam.com> > Cc: "Adam Nealis" <adamnealis@yahoo.co.uk>; <freebsd-security@FreeBSD.ORG> > Sent: Wednesday, September 26, 2001 16:25 > Subject: Re: Using ipfw pipes for bandwidth management - can it allow for > "bursting"? > > > > > > > > On Wed, 26 Sep 2001 13:24:48 -0400, Joseph Gleason wrote: > > > > > man 4 dummynet > > > > So, like, have you? :-) > > > > Seriously, Adam and I are both fairly consciencious readers, and neither > > of us can see how the RED / GRED configuration values are actually used. > > > > Ciao, > > Sheldon. > > > ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010927102735.18568.qmail>