From: David Miller <davem@davemloft.net>
To: noboru.obata.ar@hitachi.com
Cc: shemminger@linux-foundation.org, yoshfuji@linux-ipv6.org,
netdev@vger.kernel.org
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) [thread overview]
Message-ID: <20070712.023710.36923635.davem@davemloft.net> (raw)
In-Reply-To: <20070712.161510.26510093.noboru.obata.ar@hitachi.com>
From: OBATA Noboru <noboru.obata.ar@hitachi.com>
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. Application layer detects a network failure last (by, say,
> 30sec timeout) and may trigger a system-level failover.
>
> * Note 1. The timeouts for #1 and #2 are handled
> independently and there is no relationship between them.
>
> * Note 2. The actual timeout settings (20sec or 30sec in
> this example) are often determined by systems requirement
> and so setting them to certain "safe values" (if any) are
> usually not possible.
>
> If TCP retransmission misses the time frame between event #1
> and #3 in Background above (between 20 and 30sec since network
> failure), a failure causes the system-level failover where the
> network-device-level failover should be enough.
I'm still totally unconvinced, this seems pointless.
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.
I am totally unconvinced about your dom0 vs. domU notification
arguments as well.
next prev parent reply other threads:[~2007-07-12 9:37 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 [this message]
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
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=20070712.023710.36923635.davem@davemloft.net \
--to=davem@davemloft.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).