All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Liljeberg <mika.liljeberg@welho.com>
To: vda@port.imtp.ilyichevsk.odessa.ua
Cc: Dave Slicer <slice1900@hotmail.com>, linux-kernel@vger.kernel.org
Subject: Re: disabling nagle
Date: 05 Feb 2003 19:18:39 +0200	[thread overview]
Message-ID: <1044465519.1516.23.camel@devil> (raw)
In-Reply-To: <200302050648.h156mxs16371@Port.imtp.ilyichevsk.odessa.ua>

On Wed, 2003-02-05 at 08:47, Denis Vlasenko wrote:
> On 5 February 2003 02:01, Dave Slicer wrote:
> > Others already answered this specific question, but I wonder how hard
> > it would be to create a patch to disable TCP's timeout and retransmit
> > mechanisms on a given interface?  This would allow those of us who
> > have no alternative other than PPP over ssh for VPN to greatly
> > improve performance. Over a well behaved connection this works
> > acceptably, but given any delays or packet loss it is essentially
> > unusable.  I know the real answer is using something other than TCP
> > as the transport layer for the tunnel (IPSEC, IP over IP, UDP, etc.)
> > but that isn't always possible.  So I'd like a way to treat the ppp
> > interface the VPN tunnel creates as a completely reliable transport
> > for which normal TCP/IP retransmits and timeouts don't apply. It'd
> > just bullheadedly go along transmitting data and assuming it was
> > received -- the underlying TCP transport can take care of making the
> > link reliable.
> 
> I want this too ;) For one, it would be a perfect example of using
> good existing tools to achieve the goal instead of inventing
> something big and new. Also it does not reduce MTU unlike
> packet-encapsulation tunnels.
> 
> Now it's an imperfect example due to noted TCP over TCP performance
> problem ('internal meltdown').

I doubt a hack like disabling RTO would make it into the kernel.
However, try enabling F-RTO at both ends (echo 1 >
/proc/sys/net/ipv4/tcp_frto). This should improve things quite a bit.

You need at least linux 2.4.21-pre3, or linux 2.5.x.

	MikaL


  reply	other threads:[~2003-02-05 17:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-05  0:01 disabling nagle Dave Slicer
2003-02-05  6:47 ` Denis Vlasenko
2003-02-05 17:18   ` Mika Liljeberg [this message]
2003-02-06  6:35     ` Denis Vlasenko
2003-02-05 21:58 ` Olaf Titz
  -- strict thread matches above, loose matches on Subject: below --
2003-02-04 19:39 Fiona Sou-Yee Wong
2003-02-04 19:52 ` Mark Mielke
2003-02-04 20:10 ` Richard B. Johnson

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=1044465519.1516.23.camel@devil \
    --to=mika.liljeberg@welho.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=slice1900@hotmail.com \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.