From: Mark Lord <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 15:08:59 -0400
> Err.. no, the networking stack simply decided to become incompatible > with certain sites, as a result of the user adding more RAM to their > machine. Let's discuss some facts. First, you are getting window scaling by default with the older kernel too. It's just a smaller window scale, using a shift value of say 1 or 2. What these broken middle boxes do is ignore the window scale entirely. So they don't apply a window scale to the advertised windows in each packet. Therefore, they think a smaller amount of window space is being advertised than really is. So they will silently drop packets they think is outside of this bogus window they've calculated. Now, when the window scale is smaller, the connection can still limp along, albeit slowly, making forward progress even in the face of such broken devices because half or a quarter of the window is still available. It will retransmit a lot, and the congestion window won't grow at all. When the window scale is larger, this middle box bug makes it such that not even one packet can fit into the miscalculated window and things wedge. The box thinks that your window is "94" instead of "94 << WINDOW_SCALE". I think OpenBSD's claim (they did have the bug and probably still do for all that I know) was that they wanted to make their firewalling "stateless". This is a bogus argument because by definition you cannot interpret the TCP window without having seen the initial connection startup where the parameters are negotiated, and in particular the window scale which will be used. And you want to say we should try to work around systems designed by people who think this is ok? :-) It is impossible to fill a cross-continental connection without using window scaling. A 64K window is all you get without scaling. Big buffers are absolutely necessary, and as John Heffner showed this need is growing exponentially and not slowing down. 6 megabit downlink is pretty commonplace in the US, and the standard is much higher in well connected countries such as South Korea. Also, as John Heffner mentioned, even if we could detect the broken boxes you can't just "turn off window scaling" after it's been negotiated. It's immutably active for the entire connection once enabled. Window scaling has been standardized and around for 14 years, RFC1323 was published in May of 1992. How much longer can we wait for it to be deployed properly? :-) So the broken boxes, which to be honest are few and far between these days, need to go, they really do. - 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
