If each data packet had to be acknowledged before another could be sent, then performance could suffer due to the delay time needed for the data packet to reach the receiver, plus the time needed for the acknowledgment packet to get back to the sender. To avoid this delay, the sender is allowed to keep transmitting data packets prior to receiving acknowledgments (Ack's) up to a maximum "window" size (RWIN) advertised by the receiver, normally large enough for several packets. The larger the window, the more packets that can be sent before needing an acknowledgment. However, larger windows can require more packets to be retransmitted when a transmission error occurs
. Hence, the receive window size needs to be large enough to keep data flowing continuously, but it should not be excessively large.
Feedback received on this FAQ entry:
- Can we get an addendum added to this FAQ?
If you'd like to read the (gory) details, there is a thread on the Comcast forum here:
And suffice it to say, there are some folks who are misinformed (to put it lightly) about how TCP windowing works. They will accept what the tweak test tells them (the RWIN range), but fail to extrapolate exactly what it means and why it's providing a range. Can we update this FAQ to explain that while it may cause more packets to be retransmitted, the overall throughput would still likely be higher than having an RWIN cut theoretical throughput to 1/2 what it _could_ be?
Another addition I'd like to see added is a mention of the fact that each connection will negotiate a maximum RWIN which may never come close to the setting specified by DrTCP or whatever is configuring the hosts' TCP stacks. That is, just because you set the MAX RWIN to 1M, doesn't mean each connection will actually have a receive buffer that large.
Essentially, I'd like the record set straight via either a new FAQ here, or additions to the existing ones. Perhaps if folks see it published here, they will be more apt to believe it, instead of dismissing it.
Thanks for your consideration!
2008-12-15 19:28:02 (pflog )
by Pinan edited by JMGullett
last modified: 2007-02-21 16:27:40