You mean something like the gred or red qdisc.
The difference is RED drops the packets after they arrive basing it on the understanding that the TCP implementations would take this as a hint and slow down the transmission rates.
Rate control on the other hand takes a more "hands on" approach to the problem. As Jose mentioned, ack pacing, window sizing etc...it actually exploits fundamentals in TCP flow control itself.
But I wonder if it will be a big different between "TCP rate contorl" and plain old shaping.
There are lot of comparisions on this. I don't want to get into a debate here, since people from each group [rate control vs. queueing] feel very stongly about their stand.
Simply put, there are dozens of queueing 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.
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.
About the patent thing...I know for sure that ack pacing has been published in paper before. Note: I am not suggesting how to circumvent this patent in any way. That said, I think it should be possible to work out other mechanisms, based around TCP flow control, which don't work the way Packeteer's patent works.
If you google for "linux rate control", you come up with a link like:
http://www.postel.org/pipermail/end2end-interest/2001-April/000701.html
Which is a master's thesis, proposing another way to implement rate control.
Regards, -Varun
