Hi Rick,
From: Rick Jones <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Wed, 29 Aug 2007 09:16:43 -0700
> OBATA Noboru wrote:
> > What about another option to let TCP have a notification?
> >
> > Can it be a sol
From: OBATA Noboru <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 21:26:13 +0900 (JST)
> From: David Miller <[EMAIL PROTECTED]>
> Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
> Date: Tue, 28 Aug 2007 13:30:57 -0700 (PDT)
>
> > From: OBATA Nobor
OBATA Noboru wrote:
What about another option to let TCP have a notification?
Can it be a solution if it is standardized?
It would at best be a partial solution which would only work when the
link failover/whatnot happened on the same system/node as the TCP
endpoint. Then it can be some sor
From: David Miller <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Tue, 28 Aug 2007 13:30:57 -0700 (PDT)
> From: OBATA Noboru <[EMAIL PROTECTED]>
> Date: Tue, 28 Aug 2007 22:04:47 +0900 (JST)
>
> > (1) Make the applicati
From: OBATA Noboru <[EMAIL PROTECTED]>
Date: Tue, 28 Aug 2007 22:04:47 +0900 (JST)
> (1) Make the application timeouts longer. (Steve has shown that
> making an application timeouts twice the failover detection
> timeout would be a solution.)
This is the only feasible solution to your pr
OBATA Noboru wrote:
Is it correct that you think my problem can be addressed either
by the followings?
(1) Make the application timeouts longer. (Steve has shown that
making an application timeouts twice the failover detection
timeout would be a solution.)
Right. Is there something w
Hi Dave,
From: David Miller <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Thu, 12 Jul 2007 13:24:48 -0700 (PDT)
> From: OBATA Noboru <[EMAIL PROTECTED]>
> Date: Thu, 12 Jul 2007 22:59:50 +0900 (JST)
>
> > How do you
From: Rick Jones <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Thu, 12 Jul 2007 13:51:44 -0700
> > TCP's timeouts are perfectly fine, and the only thing you
> > might be showing above is that the application timeouts
> &
From: Rick Jones <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Thu, 12 Jul 2007 15:27:30 -0700
> > So the problem is that RTO can grows to be twice the failover detection
> > time. So back to the original mail, the scenario
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 13 Jul 2007 09:55:10 -0700
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-
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 13 Jul 2007 09:55:10 -0700
> 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.
The backo
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
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
So the problem is that RTO can grows to be twice the failover detection
time. So back to the original mail, the scenario has a switch with failover
detection of 20seconds. Worst case TCP RTO could grow to 40 seconds.
Going back in archive to original mail:
Background
==
When designi
On Thu, 12 Jul 2007 14:27:05 -0700
Rick Jones <[EMAIL PROTECTED]> 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
> >
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, th
On Thu, 12 Jul 2007 13:24:48 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: OBATA Noboru <[EMAIL PROTECTED]>
> Date: Thu, 12 Jul 2007 22:59:50 +0900 (JST)
>
> > How do you think TCP timeouts in Linux can adapt to such changes
> > in network environment?
>
> I'm honestly not interest
TCP's timeouts are perfectly fine, and the only thing you
might be showing above is that the application timeouts
are too short or that TCP needs notifications.
The application timeouts are probably being driven by external desires
for a given recovery time.
TCP notifications don't solve any
From: OBATA Noboru <[EMAIL PROTECTED]>
Date: Thu, 12 Jul 2007 22:59:50 +0900 (JST)
> How do you think TCP timeouts in Linux can adapt to such changes
> in network environment?
I'm honestly not interested in discussing this any more
and Ian has even showed that the RFCs state that if we have
a max
From: David Miller <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Thu, 12 Jul 2007 02:37:10 -0700 (PDT)
> Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
> From: David Miller <[EMAIL PROTECTED]>
> To: [
From: OBATA Noboru <[EMAIL PROTECTED]>
Date: Thu, 12 Jul 2007 16:15:10 +0900 (JST)
> 1. Network device layer detects a failure first and switch to a
>backup device (say, in 20sec).
>
> 2. TCP layer timeout & retransmission comes next, _hopefully_
>before the application layer timeout.
>
Hi David,
Patch (take 2) for making TCP_RTO_MAX a variable. Suggestions
from Stephen for the first version are merged. Any comments are
appreciated.
From: OBATA Noboru <[EMAIL PROTECTED]>
Make TCP_RTO_MAX a variable, and allow a user to change it via a
new sysctl entry /proc/sys/net/ipv4/tcp_r
22 matches
Mail list logo
