All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.