-----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----- - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
