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 solution if it is standardized?
It would
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 application timeouts longer. (Steve has shown
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
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 Noboru [EMAIL PROTECTED]
Date: Tue, 28 Aug
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 think TCP timeouts in Linux can adapt
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
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
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 has a switch with failover
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
are too short or that TCP needs
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
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 backoff is
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.
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
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.
3.
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: [EMAIL PROTECTED]
Cc: [EMAIL
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
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
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 interested in
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,
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
wrong with
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
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
22 matches
Mail list logo
