From: Nivedita Singhvi <niv@us.ibm.com>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: "David S. Miller" <davem@redhat.com>, bert hubert <ahu@ds9a.nl>,
Arnaldo Carvalho de Melo <acme@conectiva.com.br>,
netdev@oss.sgi.com, alessandro.suardi@oracle.com,
phyprabab@yahoo.com, linux-net@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix tcp_default_win_scale.
Date: Tue, 06 Jul 2004 13:00:07 -0700 [thread overview]
Message-ID: <40EB04C7.4000007@us.ibm.com> (raw)
In-Reply-To: <20040706114741.1bf98bbe@dell_ss3.pdx.osdl.net>
Stephen Hemminger wrote:
> Recent TCP changes exposed the problem that there ar lots of really broken firewalls
> that strip or alter TCP options.
We should not be accepting of this situation, surely. I mean, the firewalls
have to get fixed. Multiple things are breaking here, due to this. What
are the other options they are messing with, and and any idea why?
> When the options are modified TCP gets busted now. The problem is that when
> we propose window scaling, we expect that the other side receives the same initial
> SYN request that we sent. If there is corrupting firewalls that strip it then
> the window we send is not correctly scaled; so the other side thinks there is not
> enough space to send.
If the firewall is actually stripping the TCP window scaling option,
then that tells the other end that we can't *receive* scaled windows
either, since the option indicates both, we are sending and capable
of receiving. i.e. The other end will not send us scaled windows.
There is no way we can fix this on the rcv end.
> I propose that the following that will avoid sending window scaling that
> is big enough to break in these cases unless the tcp_rmem has been increased.
> It will keep default configuration from blowing in a corrupt world.
Does this need to be the default behaviour? Just how prevalent is
this??
thanks,
Nivedita
next prev parent reply other threads:[~2004-07-06 20:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <32886.63.170.215.71.1088564087.squirrel@www.osdl.org>
[not found] ` <20040629222751.392f0a82.davem@redhat.com>
[not found] ` <20040630152750.2d01ca51@dell_ss3.pdx.osdl.net>
[not found] ` <20040630153049.3ca25b76.davem@redhat.com>
2004-07-01 20:37 ` [PATCH] TCP acts like it is always out of memory Stephen Hemminger
2004-07-01 21:04 ` David S. Miller
2004-07-02 1:32 ` Arnaldo Carvalho de Melo
2004-07-06 9:35 ` analysis of TCP window size issues still around - several reports / SACK involved? bert hubert
2004-07-06 18:47 ` [PATCH] fix tcp_default_win_scale Stephen Hemminger
2004-07-06 19:40 ` Jamie Lokier
2004-07-06 20:05 ` Stephen Hemminger
2004-07-06 20:28 ` David S. Miller
2004-07-06 20:36 ` Stephen Hemminger
2004-07-06 20:35 ` David S. Miller
2004-07-06 21:55 ` John Heffner
2004-07-06 22:50 ` David S. Miller
2004-07-07 1:32 ` John Heffner
2004-07-06 23:01 ` PLS help fix: recent 2.6.7 won't connect to anything " bert hubert
2004-07-06 20:12 ` David S. Miller
2004-07-06 22:44 ` bert hubert
2004-07-06 22:49 ` David S. Miller
2004-07-07 18:06 ` Stephen Hemminger
2004-07-07 19:31 ` Jamie Lokier
2004-07-07 19:38 ` bert hubert
2004-07-07 19:41 ` John Heffner
2004-07-09 23:14 ` David S. Miller
2004-07-06 20:00 ` Nivedita Singhvi [this message]
2004-07-06 20:16 ` David S. Miller
2004-07-06 20:26 ` David Ford
[not found] ` <20040706185856.GN18841@lug-owl.de>
2004-07-06 20:17 ` David S. Miller
2004-07-06 20:31 ` Stephen Hemminger
2004-07-06 20:33 ` David S. Miller
2004-07-06 20:24 ` David S. Miller
2004-07-06 23:16 ` Andi Kleen
2004-07-07 7:50 ` Chris Wedgwood
2004-07-06 23:19 ` Redeeman
2004-07-07 19:47 ` John Heffner
2004-07-06 20:19 ` analysis of TCP window size issues still around - several reports / SACK involved? David S. Miller
2004-07-06 20:27 ` bert hubert
2004-07-06 20:31 ` David S. Miller
2004-07-07 21:25 ` Alessandro Suardi
2004-07-06 20:35 [PATCH] fix tcp_default_win_scale Tim Berti
2004-07-06 20:54 ` David Ford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40EB04C7.4000007@us.ibm.com \
--to=niv@us.ibm.com \
--cc=acme@conectiva.com.br \
--cc=ahu@ds9a.nl \
--cc=alessandro.suardi@oracle.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=phyprabab@yahoo.com \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).