Re: [LARTC] new perflow rate control queue

[Andy Furniss <andy.furniss@dsl.pipex.com>]

Wang Jian wrote:
> Hi,
> 
> One of my customer needs per flow rate control, so I write one.
> 
> The code I post here is not finished, but it seems to work as expected.
> 
> The kernel patch is agains kernel 2.6.11, the iproute2 patch is against
> iproute2-2.6.11-050314. 
> 
> I write the code in a hurry to meet deadline. There are many other things
> to do ahead for me. The code is written in 2 days (including read other
> queue's code) and tested for a while to find obvious mistake. Don't be
> suprised when you find many many bugs.

Wow - I wish I could write that in 2 days :-)

> 
> The test scenario is like this
> 
>       www server <- [ eth0   eth1 ] -> www clients
> 
> The attached t.sh is used to generate test rules. Clients download a
> big ISO file from www server, so flows' rate can be estimated by view
> progress. However I use wget to test the speed, so the speed is
> accumulated, not current.

What if the client uses a download accelerator and has 12 connections (I 
suppose server could limit this - but if client is behind nat you may 
hurt others  - which is what sfq does now AIUI, because it doesn't hash 
on dst port.)


> 
> The problems I know:
> 
> 1. The rtnetlink related code is quick hack. I am not familiar with
> rtnetlink, so I look at other queue's code and use the simplest one.
> 
> 2. perflow queue has no stats code. It will be added later.
> 
> 3. I don't know what is the dump() method 's purpose, so I didn't write
> dump() method. I will add it later when I know what it is for and how to
> write rtnetlink code.
> 
> Any feedback is welcome. And test it if you can :)
> 
> PS: the code is licensed under GPL. If it is acceptable by upstream, it
> will be submitted.

Having per flow without the drawbacks of sfq is really cool, but I agree 
with Patrick about letting htb/hfsc limit. You say in the code -

"You should use HTB or other classful qdisc to enclose this qdisc"

So if you do that (unless you meant should not) then you can't guarentee 
per flow rate anyway without knowing the number of flows, unless you can 
set rate so high that max flows x flow rate < htb rate.

I think you can still limit per flow ceil if you use htb/hfsc to ratelimit.

I suppose you are solving a different problem with this than I normally 
shape for ie. you have loads of bandwidth and I have hardly any.

It still could be something really usefull for me though, as I suspect 
it wouldn't be too hard to add lots of features/switches which (e)sfq 
doesn't have like -

Per flow queue length limit - and more choice than just tail drop (I am 
thinking of me shaping from wrong and of link here - server with BIC tcp 
is horrible with tail drop - others are not as bad).

For people who use esfq for hundreds of users, you could still do 
fairness of tcp flows within fairness per user address.

Requeue properly which (e)sfq doesn't.


Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc