From: Rick Jones <rick.jones2@hp.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
noboru.obata.ar@hitachi.com, David Miller <davem@davemloft.net>,
yoshfuji@linux-ipv6.org, Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Fri, 13 Jul 2007 09:55:10 -0700 [thread overview]
Message-ID: <4697AE6E.4070600@hp.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0707130726550.30150@kivilampi-30.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Thu, 12 Jul 2007, Rick Jones wrote:
>
>
>>>One question is why the RTO gets so large that it limits failover?
>>>
>>>If Linux TCP is working correctly, RTO should be srtt + 2*rttvar
>>>
>>>So either there is a huge srtt or variance, or something is going
>>>wrong with RTT estimation. Given some reasonable maximums of
>>>Srtt = 500ms and rttvar = 250ms, that would cause RTO to be 1second.
>>
>>I suspect that what is happening here is that a link goes down in a trunk
>>somewhere for some number of seconds, resulting in a given TCP segment being
>>retransmitted several times, with the doubling of the RTO each time.
>
>
> But that's a back-off for the retransmissions, the doubling is
> temporary... Once you return to normal conditions, the accumulated backoff
> multiplier will be immediately cut back to normal. So you should then be
> back to 1 second (like in the example or whatever) again...
Fine, but so? I suspect the point of the patch is to provide a lower cap on the
accumulated backoff so data starts flowing over the connection within that lower
cap once the link is restored/failed-over.
rick jones
next prev parent reply other threads:[~2007-07-13 16:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-12 7:15 [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2) OBATA Noboru
2007-07-12 9:37 ` David Miller
2007-07-12 13:59 ` OBATA Noboru
2007-07-12 20:24 ` David Miller
2007-07-12 21:12 ` Stephen Hemminger
2007-07-12 21:27 ` Rick Jones
2007-07-12 22:02 ` Stephen Hemminger
2007-07-12 22:27 ` Rick Jones
2007-07-24 13:30 ` OBATA Noboru
2007-07-13 4:29 ` Ilpo Järvinen
2007-07-13 16:55 ` Rick Jones [this message]
2007-07-14 6:19 ` David Miller
2007-07-23 18:40 ` Rick Jones
[not found] ` <20070828.220447.01366772.noboru.obata.ar@hitachi.com>
[not found] ` <20070828.133057.107937654.davem@davemloft.net>
2007-08-29 12:26 ` OBATA Noboru
2007-08-29 16:16 ` Rick Jones
2007-08-30 12:24 ` OBATA Noboru
2007-08-29 18:15 ` David Miller
2007-07-12 20:51 ` Rick Jones
2007-07-24 13:35 ` OBATA Noboru
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=4697AE6E.4070600@hp.com \
--to=rick.jones2@hp.com \
--cc=davem@davemloft.net \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=netdev@vger.kernel.org \
--cc=noboru.obata.ar@hitachi.com \
--cc=shemminger@linux-foundation.org \
--cc=yoshfuji@linux-ipv6.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 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.