Packet Loss

[Lobo]

I would like some kind of clairification of this, at one time size of RWIN did matter concerning packet loss, then we were told it did not, now I find this which says it does, does anyone know?


TCP Receive Window: This is where you set RWIN (RcvWindow). RWIN is the single most important tweak. Raising Rwin from default (8192 for Win95/98/98SE/NT and 16384 for WinME/2K), can greatly improve download speeds. Why? Here is my kindergarten analogy: Default RWIN for broadband, is like having a tiny straw in a thick milk shake, only so much can get through the straw (line), so fast. By putting a larger straw (higher RWIN) in that same thick shake, you allow more shake (data) to come through faster, to a point that is. After which, there is no more improvement, and shake (data) can start spilling all over (packet loss). So the key is, to find an RWIN that fits your line just right. This is blank before changing from default.

:) :) :) :)

[lance-tek]

:D

[Juggernaut]

I believe it does. You must find a good RWIN that works best for your system...everyone is different. A very high RWIN, while allowing you more data to get through, if your line and computer can't handle it, it will "spill over" and be packet loss. Then you just lower it down and test some more. Find what works best for you.

[Kip Patterson]

The relationship between RWIN and packet loss goes as follows:

Whenever a TCP/IP connection is negotiated, the sender and receiver agree on the number of bytes that the sender may send without receiving an acknowledgement from the receiver. That number has to be no greater than the receiver's RWIN. I'm going to call this number the negotiated window, since I forget the official name in the RFC's.

Once the connection is negotiated, the sender goes ahead and sends as many bytes as it takes to fill the negotiated window. It then stops and waits for acknowledgements from the receiving computer. Once it receives an acknowledgement for, say, 3,000 bytes, it then is free to send another 3,000 bytes.

Now, let's say that the window is 65kbytes, and that the packet corresponding to bytes 20,001 thru 21,500 is lost. Eventually, the sending computer realizes that there has been plenty of time for the packet to get to the far end, so it resends it. It also resends all the following packets. (I'm describing how it worked before selective acknowledgements were added to the TCP/IP protocol.)

Nothing in the setting of RWIN causes or prevents packet loss, but it can have a big effect on the channel throughput. If there is a lot of packet loss, the sender wastes time and bandwidth sending data that is thrown away, since the original TCP/IP protocol restarts the send beginning with the lost packet, even though subsequent packets arrived without problem.

So, how big should RWIN be? If you are on a cable modem, dealing with sites in North America, you should not see a propagation time (ping) much over 100 ms. On a 2mbit cable modem connection, assuming that the cable modem connection is the limiting factor, you can receive 25kbytes in 100ms. The first acknowledgement will be back at the sender in time to transmit more data and get it to the receiver before the first 25 K has been received. So, a 65k window far exceeds what most cable modem connections can handle. Anything more is likely to degrade the speed of the connection.

The later implementations of TCP/IP include selective acknowledgements, which is a technology which permits the rejection of only the bad/lost packets and eliminates the need to resend every packet beginning with the bad/lost packet. These make the net more efficient, but don't change the basic rule that the RWIN should be equal to or greater than the speed of the slowest network segment divided by the ping (in seconds)

Kip

[Lobo]

So to make it short as Cablenut has already told us RWIN size does not matter :) :) :)



Lance, now when you get back from peeling potatoes you will know,hehe