David S. Miller wrote:
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 13:55:49 -0800 (Pacific Standard Time)
In this configuration, with e100, e1000, and others, I see the window size
grow to 32767 and stop.
Without window scaling enabled, this is the largest window we can
use in order to interoperate with older TCP implementations that
used a signed 16-bit value to store the window value. Any value
larger than 32767 would be considered negative by such implementations.
>
You should always have window scaling enabled. You can't even fill a
cross-continent connection in the United States with that size of
window.
Window scaling on is certainly goodness, but it seems that ass-u-me-ing that
!winscale == signed windows is overly conservative.
Maybe there is more ancient kit out there than I realized, but I thought that
stacks the signed window bug went the way of the buggy whip about 10 years ago.
Perhaps more.
I do know that there _are_ TCP's out there which properly treat the window as
unsigned but may not necessarily negotiate window scaling when the window is to
be < 65535 bytes.
And while I'm not suggesting that seeing _any_ option should be required to
allow the window to go all the way to 65535 bytes; in Jesse's trace, we see
timestamp and sackOK options, both of which suggest (to me at least) that the
stack is new enough to properly recognize that the TCP window field is an
unsigned quantity. Again though, given how long it has been since the TCP
window as signed bug has been around, it seems no TCP option should be required
to be seen to allow the window to grow to 65535 bytes.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
