[LARTC] new perflow rate control queue

[Wang Jian]

Hi Andy Furniss,



On Tue, 05 Apr 2005 23:40:54 +0100, Andy Furniss <andy.furniss at dsl.pipex.com> wrote:

> > 
> > Looking forward to your feedback :)
> 
> It works OK for me - though I would really need it to be variable rate 
> to use really - but as you say it's designed for your needs.
> 
> I noticed that it drops icmp so you need to be careful about what you 
> send to it.

I plan to optionally reclassify unhandled traffic to another class if specified.
So a default class may handle it.

> 
> If you limit connections and use them all up then alive but not always 
> active connections will get locked out - there is a netfilter connection 
> limit already.
> 
> As you say above it's not always fair - I didn't test that much it 
> seemed OK apart from if htb limited it ie.
> 
> htb rate higher than sum of rates but less than sum of ceils made it 
> unfair to a flow with smaller packet size.

Yes. I also think that low rate or small packet size stream will have problem.
I didn't test that case yet. 

I read back your post and I think the best solution for you is use HTB +
PRIO.

Let interactive but low rate traffic have highest priority, and let bulk
transfer have lowest priority and constrain them using HTB.

TCP itself has some fairness: slower stream get faster, and faster
stream get slower. The sliding window is for this.



-- 
  lark