From: "Edgar E. Iglesias" <edgar.iglesias@axis.com>
To: David Miller <davem@davemloft.net>
Cc: rick.jones2@hp.com, ian.mcdonald@jandi.co.nz, netdev@vger.kernel.org
Subject: Re: [PATCH] make _minimum_ TCP retransmission timeout configurable
Date: Thu, 30 Aug 2007 00:53:00 +0200 [thread overview]
Message-ID: <20070829225300.GA15652@edgar.underground.se.axis.com> (raw)
In-Reply-To: <20070829.153503.18295527.davem@davemloft.net>
On Wed, Aug 29, 2007 at 03:35:03PM -0700, David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Wed, 29 Aug 2007 15:29:03 -0700
>
> > David Miller wrote:
> > > None of the research folks want to commit to saying a lower value is
> > > OK, even though it's quite clear that on a local 10 gigabit link a
> > > minimum value of even 200 is absolutely and positively absurd.
> > >
> > > So what do these cellphone network people want to do, increate the
> > > minimum RTO or increase it? Exactly how does it help them?
> >
> > They want to increase it. The folks who triggered this want to make it
> > 3 seconds to avoid spurrious RTOs. Their experience the "other
> > platform" they widh to replace suggests that 3 seconds is a good value
> > for their network.
> >
> > > If the issue is wireless loss, algorithms like FRTO might help them,
> > > because FRTO tries to make a distinction between capacity losses
> > > (which should adjust cwnd) and radio losses (which are not capacity
> > > based and therefore should not affect cwnd).
> >
> > I was looking at that. FRTO seems only to affect the cwnd calculations,
> > and not the RTO calculation, so it seems to "deal with" spurrious RTOs
> > rather than preclude them. There is a strong desire here to not have
> > spurrious RTO's in the first place. Each spurrious retransmission will
> > increase a user's charges.
>
> All of this seems to suggest that the RTO calculation is wrong.
>
> It seems that packets in this network can be delayed several orders of
> magnitude longer than the usual round trip as measured by TCP.
>
> What exactly causes such a huge delay? What is the TCP measured RTO
> in these circumstances where spurious RTOs happen and a 3 second
> minimum RTO makes things better?
I don't know what they are doing, but it reminds me of what happens when
you run TCP over a reliable medium. You don't see loss, instead the
RTT starts to jitter alot.
IIRC FRTO does help avoid unnecessary retransmits (although the RTO still
hits).
Best regards
--
Programmer
Edgar E. Iglesias <edgar.iglesias@axis.com> 46.46.272.1946
next prev parent reply other threads:[~2007-08-29 23:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-29 20:52 [PATCH] make _minimum_ TCP retransmission timeout configurable Rick Jones
2007-08-29 21:13 ` Eric Dumazet
2007-08-29 22:11 ` Rick Jones
2007-08-29 21:32 ` Ian McDonald
2007-08-29 21:46 ` David Miller
2007-08-29 22:10 ` Ian McDonald
2007-08-29 22:23 ` David Miller
2007-08-29 22:13 ` Stephen Hemminger
2007-08-29 22:28 ` David Miller
2007-08-29 22:51 ` Stephen Hemminger
2007-08-29 22:58 ` NCR, was " John Heffner
2007-08-29 22:59 ` David Miller
2007-08-29 22:32 ` Rick Jones
2007-08-29 22:29 ` Rick Jones
2007-08-29 22:35 ` David Miller
2007-08-29 22:48 ` John Heffner
2007-08-29 22:52 ` John Heffner
2007-08-29 22:53 ` Edgar E. Iglesias [this message]
2007-08-29 23:06 ` Rick Jones
2007-08-29 23:15 ` David Miller
2007-08-29 23:31 ` Rick Jones
2007-08-30 5:22 ` Krishna Kumar2
2007-08-30 17:10 ` Rick Jones
2007-08-29 23:44 ` John Heffner
2007-09-05 19:04 ` Ilpo Järvinen
2007-09-06 20:39 ` David Miller
2007-08-29 22:09 ` Rick Jones
2007-08-29 22:20 ` David Miller
2007-08-29 22:33 ` Ian McDonald
2007-08-29 22:37 ` David Miller
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=20070829225300.GA15652@edgar.underground.se.axis.com \
--to=edgar.iglesias@axis.com \
--cc=davem@davemloft.net \
--cc=ian.mcdonald@jandi.co.nz \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
/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.