Re: Suggestions for a new shaper

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kenneth Kalmer wrote:
Guys
Hi,

First the case study. An untrusted network with over-subscribed users
(and abusers). Common at universities and bigger enterprises. People
want good speed at any time, but abusers should be detected and
clamped down automatically. This system needs intelligence. Let's say
a good combo between HTB & WRR, through in a pacemaker and the
configurability of XML files.
I have a lot of experience in networks like this, so I'll post some comments:

My thinking is Python (I only code interpreted) doing the
configurations and "live" htb manipulation to simulate wrr, but still
offer the gaurentees of htb.
I have heard that HTB doesn't scale well when you have it arranged in this way (search "Ostrochovsky" in the archives, or perhaps it was another list => use google). This would have to be analysed. Usually I avoid it by creating more levels (think binary tree), but I don't have any measurements on high load.

WRR on the other hand has many advantages: it scales very well, automatically penalizes abusers, and behaves predictably (I performed a statistical-mathematical analysis of one such case last week, got great results). There is one problem though: what it distributes is actually sending frequency, not bandwidth. Therefore, you can't set limits to traffic of individuals, you can't give anyone "guaranteed" bandwith, or give someone "twice as much bandwidth as the others". You can set it up so that certain IPs are penalized less or more, but there is no way to give them specific bandwidth.

In my experience (my customers) sometimes want to set specific bandwidths, but after using WRR for some time, due to its fairness characteristics they decide it's not necessary. A commercial ISP may have different requirements though, so that they can sell different bandwidths for different prices.

Although I don't have a mathematical proof :-), I think that these two approaches are mutually exclusive. If you want predictable behaviour (no latency peaks), you can either give individual people specific bandwidth, or you can utilize the bandwidth fully. You can't utilize the whole bandwidth while giving people specific amounts of it.

Nevertheless, I have some ideas how to bring certain advantages of HTB to WRR: - if you want to cap someone, you may be able to use a htb inside one wrr-subclass - if you want to guarantee someone's bandwidth, give him a permanently higher weight (cap others to a lower weight), put htb there and set its rate

(For comparison, I use ESFQ inside the wrr-subclasses).

I'd like to stress however that you lose a lot of WRR's predictability if you manually fiddle with the settings. This would have to be tested extensively.

Extra things should be the ability to handle multiple subnets, not
just a single one,
WRR handles multiple subnets without problems and without the need to set anything (classes are assigned dynamically as the IPs appear).

> and while doing Python we might as well have
options to produce rrd's to make sure that everything is running
perfectly.
Sorry for advertisement (again). Shurdix already does this, most of it automatically (and uses perl, but the scripts are very simple). I use ipt_ACCOUNT for accounting because I want it to be independent from traffic control, but WRR has it's own accounting method (look on their website, it is also more precise, because iptables-based accounting doesn't know about packets that are dropped while doing egress).

Any advice, tips or suggestions? I know it won't be an easy feat, but
it is worth a shot...
As I said, the first thing you should do is to set your priorities:
- if you want to utilise the bandwidth fully, go WRR
- if you want to set specific parameters, go HTB

And you have to test, test, test, because if you lose predictability you're screwed :-).

Best
Kenneth Kalmer
Yours sincerely,
Peter

--
http://www.shurdix.org - Linux distribution for routers and firewalls
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux