I have the same problem on a different setting: I am implementing an....
alternative congestion control algorithm for very high-latency, high-bandwidth, etherogeneus lossy networks (like UMTS).
Our sender side algorithm (TCP Hybla) tries to enlarge CWND more quickly than standard, since NewReno performs very badly under these conditions. But pif >= CWND conditional before the call to tcp_cong_avoid() cuts down our expected CWND value in the initial slow start phase, though it also limits the overshoot at the end of it, resulting in a better threshold estimation after first Recovery.
My feeling is that this conditional is required to achieve better performances in the Recovery phase, since linux doesn't cut down the CWND to its half immediately after 3 received dupacks, but does it steadily, applying Hoe's Rate Halving algo.
Rate Halving, indeed, seems to require CWND value to be closer to real outstanding segments on the network to work well.
Could this be our mysterious conditional real purpose?
Very cool. I couldn't quite articulate it, but this area was the one concern I had about what that conditional guarded. This gave great insight to me on the purpose of RFC 2861 (which I've just re-read for the n-teenth time... :-) ), which I think covers this case.
Increasing cwnd for each ack will only result in a bad cwnd (and thus eventually a bad ssthresh when congestion is finally observed) only if the sender is application limited. In this case, cwnd should either be reset to rw (due to long idle per RFC 2581) or decayed based on RTT measurements (per RFC 2861). It does look like this is fully implemented (tcp_cwnd_validate(), tcp_cwnd_appliciation_limited()), so I still don't see a reason behind the pif/cwnd conditional....
Cool stuff. Thank you all for the responses.
Ted
- : 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
