You are not logged in. Login Now
 0-10          
 
Author Message
gelinas
Controlling Bandwidth Usage Mark Unseen   Jan 20 01:18 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.
cross
response 1 of 10: Mark Unseen   Jan 20 01:24 UTC 2005

ALTQ traffic shaping with pf.

I can't seem to find a good reference for it at the moment, though.
gelinas
response 2 of 10: Mark Unseen   Jan 20 01:37 UTC 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.
gull
response 3 of 10: Mark Unseen   Jan 21 01:16 UTC 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.
gelinas
response 4 of 10: Mark Unseen   Jan 21 05:54 UTC 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.
gelinas
response 5 of 10: Mark Unseen   Jan 21 06:49 UTC 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?
gull
response 6 of 10: Mark Unseen   Jan 21 21:27 UTC 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.
cross
response 7 of 10: Mark Unseen   Jan 22 02:17 UTC 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.
gelinas
response 8 of 10: Mark Unseen   Jan 23 02:17 UTC 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.
sj2
response 9 of 10: Mark Unseen   Feb 13 05:56 UTC 2005

Re #0, On FreeBSD, you have dummynet. Look it up too:
http://info.iet.unipi.it/~luigi/ip_dummynet/
eteepell
response 10 of 10: Mark Unseen   Jan 6 20:04 UTC 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?
 0-10          
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss