Grex Garage Conference

View Responses

Grex Garage Item 4: Controlling Bandwidth Usage
Entered by gelinas on Thu Jan 20 01:18:12 UTC 2005:

When we move to provide.net's colocation facility, we will have more
bandwidth available than we have contracted for.  So we will need to
implement some form of traffic limitation on our end.  What is the 
best way to do that?

10 responses total.

#1 of 10 by cross on Thu Jan 20 01:24:51 2005:

ALTQ traffic shaping with pf.

I can't seem to find a good reference for it at the moment, though.

#2 of 10 by gelinas on Thu Jan 20 01:37:21 2005:

Right now, we are using OpenBSD's pf, which includes a queueing option.  I'm
thinking we should set up something like three queues, each with a percentage
of the total bandwidth.  Note that pf's queues cannot restrict incoming
traffic, though.

The three queues I would set up, and their percentages, are:

        mail    45%
        ftp     10%
        other   45%

If I have done the arithmetic correctly a 50 Gigabyte/month transfer rate is
something like 20 kilobytes per second.

#3 of 10 by gull on Fri Jan 21 01:16:23 2005:

If you can, I'd apply a higher priority to telnet and ssh packets.  I used
to do this when I was using a low-bandwidth SLiRP link, and the improvement
in the responsiveness of telnet sessions during file transfers was
impressive.

#4 of 10 by gelinas on Fri Jan 21 05:54:06 2005:

I discovered that any queue must be of minimu size, something like 5.5Kb, so
I ended up with a 30/30/40 division.

I'll take another look at setting priority.

#5 of 10 by gelinas on Fri Jan 21 06:49:12 2005:

I also renamed "other" to "interactive."  Right now, any traffic bound for
the 'open' prots (those ports available to both non-members and members)
is assigned to the "interactive" queue: http, talk, etc.  telnet and ssh
packets (for members) are also assigned to that queue.

Should the "interactive" queue be divided into sub-queues?

#6 of 10 by gull on Fri Jan 21 21:27:37 2005:

I'd be inclined to keep it simple for now.  If there's a need you can
experiment with adding more sub-queues later, when you have a baseline to
judge from.

#7 of 10 by cross on Sat Jan 22 02:17:26 2005:

About the only thing I'd change is to put http in it's own queue.  Then
things retrieved from grex's public web spaces and user home pages won't
bog down the rest of the network link.

#8 of 10 by gelinas on Sun Jan 23 02:17:58 2005:

So I now have:

        queue interactive bandwidth 40% cbq(default,borrow)
        queue mail bandwidth 20% cbq(ecn)    
        queue ftp bandwidth 20% cbq(ecn)
        queue web bandwidth 20% cbq(ecn)

The things left to determine are the size of the bandwidth in the command

  altq on $ext_if bandwidth 100Kb cbq queue { mail, ftp, web, interactive }

and whether this actually works for us.

#9 of 10 by sj2 on Sun Feb 13 05:56:15 2005:

Re #0, On FreeBSD, you have dummynet. Look it up too:
http://info.iet.unipi.it/~luigi/ip_dummynet/

#10 of 10 by eteepell on Sun Jan 6 20:04:53 2008:

Is there any easy way to "bank" idletime bandwidth or does it have to be 50
Gigabyte/month transfer rate is
 something like 20 kilobytes per second shaping?

Response not possible - You must register and login before posting.