On Wed, 31 Aug 2005 00:57:16 +0200 Daniele Lacamera <mlists@xxxxxxxxxxxxxx> wrote: > > I am evaluating the Westwood protocol in the lab using NISTnet as an > > emulator. So far I am seeing little to zero improvement of TCP > > performance using Westwood as opposed to the Vegas implementation in > > the kernel. > We did a lot of tests like yours. Angelo's Westwood+ seems to perform > much better on long TCP connections. Try to make a longer connection > (i.e. 300-600 sec.) and see if something changes. This is absolutely right. In fact, TCP Westwood+ bandwidth estimation is done through the use of a low-pass filter which requires few RTTs for obtaining the right value for the estimation. This is a transient and we simply can't avoid it. If the data transfer ends before the end of the transient you're simply not testing Westwood+. Moreover, as a general way of proceeding, I think that running few different TCP congestion control algorithms for just few RTTs and then comparing the results is not a correct way to proceed. In the first phase of a TCP connection it's not possible to know how large is the pipe and the Reno slow start was designed in that way just for this reason (obtaining an estimation of the capacity of the pipe as soon as possible). This is a blind phase and IMHO no algorithm could be designed to be better than others during this phase. I can just take Reno and make its slow start phase more aggressive and so obtaining better results in the first RTTs but this doesn't mean this "new algorithm" is better than Reno. > Also you can try to enlarge tcp_wmem, as with such a delay you need > more memory for TCP buffers. Absolutely true. Regards. -- Angelo Dell'Aera 'buffer' Antifork Research, Inc. http://buffer.antifork.org Metro Olografix PGP information in e-mail header
Attachment:
pgpxpcsa3mCJY.pgp
Description: PGP signature
