|
|
| Author |
Message |
gelinas
|
|
Controlling Bandwidth Usage
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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?
|