The application sends anywhere from 32 to 64 little (50 byte) messages. I agree completely that the fact that cwnd is determined by packets and not bytes complicates the matter (especially when a very large network MTU is used). However, I think this disparity would cause cwnd to be increased too aggresively given the true knowledge the TCP is gleeming from the network based on successful acks. In this case, the ack of a 50 byte message results in cwnd being increased a full packet size (1500 bytes, 9k, or whatever else the MTU might be).
How many little messages is this? I think this is really caused by the
fact that delayed ack is determined by bytes, but cwnd is in packets.
What I don't understand is why you don't run into this problem with GigE. Could you get some tcpdumps? Does cwnd somehow get ramped up during Step 1?
The problem only occurs when the packets-in-flight calculation is always low. This can be caused by a very low latency network (i.e -- acks come back so quickly, pif is always very small). With suficiently high latency (and a pif that is sufficiently large), then cwnd gets ramped up in the first step when the application is bi-directionally conversational.
I think that that test does not belong there, anyway. Could the author
comment?
I have just responded to Daniele Lacamera's post above, which touchs on the congestion window avoidance algorithm (RFC 2861). This does appear to be implemented correctly in the current Linux TCP, and does not use a packets-in-flight calculation to modulate cwnd.
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
