There are lot of comparisons on this. I don't want to get into a debate here, since people from each group [rate control vs. queuing] feel very strongly about their stand.
But I'm still intested in the comparision :)
It's you quest for the truth that endears you to all of us. :)
Googling for "tcp rate control" would lead you to a lot of material, including documents "proving" queuing is better than rate control.
Here's the test jig I plan to setup...
Windows client running Gozilla, for crude throughput reporting
|
|(1)
|
->"Gateway" m/c with two NICs [RTL8139 based] running nisnet and tbf, iptraf and MRTG--
|
|(2)
|
->Linux based FTP/HTTP Server
I will try with sustained downloads, perhaps 1GB. The tbf would be set to limit at 100kbps.
From what I expect, I would only get 100kbps on the windows client m/c, i.e. at point (1). But between the gateway and server, i.e. point (2), the bandwidth consumption would be higher. How much higher I don't know - it might be anything from 100kbps to NIC speed. If it is within a 5% tolerance, i.e. from 95kbps to 100kbps, I would say that the world is a great place and I am happy to be here...i.e. queuing would have achieved what I want.
But, I suspect the difference would be much more...
Would most probably do this on this weekend and publish my results. I don't have too much experience with tc, so I might get the values wrong for the tbf.
Has anyone done this kind of test? Where can I get some published results? All the tests I have seen are done from the client perspective...or is it just a case of RTFM?
I am going to go ahead with the test in any case.
This only tests one side of the story. I have tested two commercial solutions and can testify that they give very fine-grained control on the bandwidth, albeit at the cost of huge latency fluctuations. Don't have access to these units right now, so won't be able to include the results from there.
I as see it, if the above test goes as I think it would, then that itself is a strong case for looking into other mechanisms.
Simply put, there are dozens of queuing disciplines, because some might "behave better" than other in some cases. I *feel* that rate control would work better in some particular cases, so I was interested in knowing if a rate control like implementation is available under Linux.
Not in the default linux kernel.
I have been tracking the tc development for quite some time, and have been hoping for someone to develop this.
Seems to be a patented "idea" in the USA, but I remember someone on this list talked not long ago about he waaas implementing something like this for Linux, from outside the USA. Check the archives for the message: Subject: Re: [LARTC] How far can TC go? From: Patrick McHardy <kaber@xxxxxxxxx> Date: Sat, 29 Mar 2003 11:08:30 +0100
Thanks for the reference...still need to check it out.
I already did :
Packeteer has various patents covering tcp rate control and everything else
they do, including the "idea" to look at upper layers to detect the type of traffic.
I live in germany so i don't really care that much about their patents (they had none in europe last time i checked). last summer i started implementing tcp rate control as qdisc for linux. i haven't worked on it for a couple of month now, but if anyone wishes to participate i would be glad to dig out my source again. it is basically working, the remaining problems are mostly how to detect and handle interactive traffic.
Patrick
Like I said, it's you quest for the truth that endears you to us!
Regards, -Varun
