Hi, Nice to see the Westwood patch. It'll be interesting to try it out. On Fri, 2004-01-16 at 00:59, David S. Miller wrote: > It would be very interesting to see how westwood+ compares to F-RTO, in > particular over wireless networks since both purport to improve things over > such technologies. I guess the two algorithms try to tackle a bit different case: Westwood modifies the congestion control with the intention is to improve congestion control behaviour after corruption-related packet losses (right?). F-RTO is meant for detecting spurious RTOs (e.g. for delay spikes due to error recovery at the lower protocol layers) and avoid unnecessary retransmissions (and excessive congestion control) after that. I think Westwood and F-RTO should be usable together, although I haven't yet checked the patch for any interactions there may be. > Also, it would be interesting, once we have a working TCP Vegas implementation > again, to see how combinations of Westwood+/VEGAS and F-RTO/Vegas compared > to flat new-reno. In particular, since VEGAS attempts to avoid the packet loss > from happening in the first place, and if it does still happen Westwood+/F-RTO will > handle them more gracefully, the overall result should be something approaching > the sum of the parts :-) Ideally, that would be the case. Except if under some specific conditions the combination of algorithms start to be counter-productive. For example, what would happen with Vegas congestion control if the RTT suddenly increased remarkably for a short while? > Baring some huge problem, I would be happy to put a cleaned up > Westwood+ in the kernel, available always, but disabled by default via > sysctl (as I believe is implemented in your patch) until we have more experimental > results. This would be great. - Pasi - : 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
