Re: [LARTC] TCP Rate Control

[Varun Varma <varun@mindsw.com>]

Stef,

>>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@trash.net>
>>>>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


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/