Hi people. Friday 14 November 2003 17:33, Ted Duffy wrote: > Hi, <cuts here and there> > Detailed analysis of TCP packets and the Linux TCP implementation > showed that the sender congestion window was being opened very slowly > on Egenera hardware, artificially limiting TCP throughput. The cause > for the slow expansion of the sender congestion window is a > combination of two factors -- very low network latency, and the > following conditional in tcp_ack() in net/ipv4/tcp_input.c: > prior_in_flight >= tp->snd_cwnd > > This conditional prevents the congestion algorithm from executing if > the number of outstanding packets is less than the sender's > congestion window. 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. > After reading over RFC 2581, and other TCP-related RFCs (793, 2861, > 1323, 1337), I can find no explanation for the limit being placed on > the execution of the congestion avoidance algorithm as is currently > done by that one conditional in tcp_ack(). My interpretation of RFC > 2581 is that during slow start (the initial congestion avoidance > algorithm state), the sender congestion window should be increased by > a packet at every received ack. This should continue until > congestion is observed or the sender congestion window exceeds the > slow start threshold, at which point the congestion avoidance > algorithm should enter the congestion avoidance state. > > During the congestion avoidance state, the RFC does recommend to > increase the sender congestion window in step with an > outstanding-packet concept. However, this already appears to be > implemented in tcp_cong_avoid() via the snd_cwnd_cnt variable. > > So, I am trying to grasp the reasoning behind the tcp_ack() > conditional mentioned above, and recommend removing this conditional. > Removing the conditional allows the sender congestion window to > increase far more quickly and higher than currently, but I think > that is the intent -- this should increase indefinitely until it hits > ssthresh or there is congestion detected. 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? regards, -- Daniele Lacamera root@danielinux.net - : 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
