TCP congestion control article

TCP congestion control article

[Angelo Dell'Aera]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Hi all,
I just want to point out to you a really interesting article published
by  two  members   of  my  research  group.  The   paper  is  entitled
"Performance  Evaluation and  Comparison  of Westwood+,  New Reno  and
Vegas TCP  Congestion Control" and  it aims at evaluating  these three
algorithms in really different scenarios.

You may find it at

http://buffer.antifork.org/westwood/ccr_v31.pdf


Best regards.

 
- --

Angelo Dell'Aera 'buffer' 
Antifork Research, Inc.	  	http://buffer.antifork.org

PGP information in e-mail header


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA3AD5pONIzxnBXKIRArSJAJ9AZoybNpTpLxj2XPZ3IBm/zfgfzwCguu3m
+XKmZTP/fvy73EM5MHOUY6g=
=0DyV
-----END PGP SIGNATURE-----

Re: TCP congestion control article

[David S. Miller]

On Fri, 25 Jun 2004 12:39:53 +0200
"Angelo Dell'Aera" <buffer@antifork.org> wrote:

> I just want to point out to you a really interesting article published
> by  two  members   of  my  research  group.  The   paper  is  entitled
> "Performance  Evaluation and  Comparison  of Westwood+,  New Reno  and
> Vegas TCP  Congestion Control" and  it aims at evaluating  these three
> algorithms in really different scenarios.

Would be interesting to compare with BITCP which we have enabled
by default now in current 2.6.x kernels.

Re: TCP congestion control article

[Angelo Dell'Aera]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 25 Jun 2004 09:11:58 -0700
"David S. Miller" <davem@redhat.com> wrote:

>On Fri, 25 Jun 2004 12:39:53 +0200
>"Angelo Dell'Aera" <buffer@antifork.org> wrote:
>
>> I just want to point out to you a really interesting article published
>> by  two  members   of  my  research  group.  The   paper  is  entitled
>> "Performance  Evaluation and  Comparison  of Westwood+,  New Reno  and
>> Vegas TCP  Congestion Control" and  it aims at evaluating  these three
>> algorithms in really different scenarios.

>Would be interesting  to compare with BITCP which  we have enabled by
>default now in current 2.6.x kernels.

Dave,
I had suggested  to do this to the members of  my research group since
I'm goin' away from there. But I wanted to say just few things.

First of all I  know not too much about BITCP but  I think it's unsafe
to enable it by default... just  like it's unsafe to enable by default
any kind of new congestion control algorithm.

I worked  in this research  field in  the last year  and a half  and I
realized that the perfect algorithm doesn't exist.  For example in the
paper  about BITCP  I  read  it's `RTT  fair'  since its  steady-state
throughput  is  inversely  proportional   to  RTT  (the  same  as  TCP
NewReno). In  this situation, TCP Westwood+ behaviour  is better since
its steady-state  throughput is  inversely proportional to  the square
root of RTT.

But TCP  Westwood+ has no so smart  mechanisms as BITCP in  a long fat
pipe context.  So different  scenarios lead to  different performances
for these algorithms.

So IMHO I think the default should always be TCP NewReno and we should
give the possibility to anyone to  choose what he/she wants to use for
his/her purposes.

Another thing.  I think it's  necessary to provide some  mechanism for
enabling  just one  of these  algorithms at  a time.  Some days  ago I
started 2.6.7-mm1 and I found  myself with BITCP and Westwood+ enabled
at  the same  time. Maybe  in  the future  a merge  between these  two
algorithms could even be a good thing to realize but now I had no time
to look at the sources for realizing if `crazy things' could happen...
what do you think about it?

And just another thing. I think TCP Vegas is a quite good example of a
first try  of realizing a  smart congestion control algorithm  but too
many studies  has shown  it's unable to  work properly in  presence of
reverse traffic (which happens almost  always in the real world). Yes,
it is fair..  but I think it's not enough. IMHO  no one wants fairness
throwing away bandwidth..  Conclusion : IMHO TCP Vegas patch has to be
reversed...


Regards. 


- --

Angelo Dell'Aera 'buffer' 
Antifork Research, Inc.	  	http://buffer.antifork.org

PGP information in e-mail header


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA4bYqpONIzxnBXKIRAsdrAJ9zdutB1m5HbDbvXBk/ouqTrJ5AHgCePetU
pdcoVDk/Gcu0VAsvsA21aq4=
=lt0y
-----END PGP SIGNATURE-----

Re: TCP congestion control article

[David S. Miller]

On Tue, 29 Jun 2004 20:34:18 +0200
"Angelo Dell'Aera" <buffer@antifork.org> wrote:

> First of all I  know not too much about BITCP but  I think it's unsafe
> to enable it by default... just  like it's unsafe to enable by default
> any kind of new congestion control algorithm.

I disagree.  In Stephen Hemminger and my own usage, BICTCP even
improved performance in cases where we had mistakenly misconfigured
our systems.  That, frankly, is impressive.

Because it deals with long-fat-pipe issues as well, was another reason
we choose to enable it over westwood+.

> Another thing.  I think it's  necessary to provide some  mechanism for
> enabling  just one  of these  algorithms at  a time.

We do, you turn one on and another one off. :-)

I discussed this with Stephen the other week.  We came to the conclusion
that enabling both algorithms at the same time is valid, and we should
not put obstacles in the way to prevent people who wish to do this.
It might even be beneficial in some situations.

I agree with your analysis of Vegas, and that is why I did not enable it
by default.  It has it's own set of problems, although I like many
aspects of it.