[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070724.223558.73364253.noboru.obata.ar@hitachi.com>
Date: Tue, 24 Jul 2007 22:35:58 +0900 (JST)
From: OBATA Noboru <noboru.obata.ar@...achi.com>
To: rick.jones2@...com
Cc: davem@...emloft.net, shemminger@...ux-foundation.org,
yoshfuji@...ux-ipv6.org, netdev@...r.kernel.org
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
From: Rick Jones <rick.jones2@...com>
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 notifications.
>
> The application timeouts are probably being driven by external desires
> for a given recovery time.
Agreed.
> TCP notifications don't solve anything unless the links in question are
> local to the machine on which the TCP endpoint resides.
Agreed. Thank you for a good explanation.
My original discussion using Dom-0 and Dom-U might be
misleading, but I was trying to say:
* Network failure and recovery(failover) are not necessarily
visible locally.
** Dom-0 vs. Dom-U discussion is just an example of the case
where a network failure is not visible locally.
** For another example, network switches or routers sitting
somewhere in the middle of route are often duplicated with
active-standby setting today.
* Quick response (retransmission) of TCP upon a recovery of such
invisible devices as well is desired.
* If the failure and recovery are not visible locally, TCP
notifications do not help.
Regards,
--
OBATA Noboru (noboru.obata.ar@...achi.com)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists