netdev - Re: [PATCH 2.6.22] TCP: Make TCP_RTO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Aug 2007 22:04:47 +0900 (JST)
From:	OBATA Noboru <noboru.obata.ar@...achi.com>
To:	davem@...emloft.net
Cc:	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)

Hi Dave,

From: David Miller <davem@...emloft.net>
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 <noboru.obata.ar@...achi.com>
> 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 maximum it must be at least 60.
> 
> So really, there is no chance of merging a TCP_RTO_MAX
> decreasing patch, sorry.

My apologies for replying this late as I have no idea what I can
do next at this point.

But let me throw away my TCP_RTO_MAX decreasing patch and step
back to the original problem to continue discussion.

The original problem was:

* A TCP packet is delayed upon a physical failure of a
  failover-and-recovery-capable network, until the failure is
  detected and recovered.  The RTO of packet grows exponentially
  (say, up to 10 or 15 seconds) during failure detection and
  recovery.

* While the application expects the TCP packet to be sent just
  after the recovery, but it may not necessarily be
  retransmitted immediately because of a large RTO.

* Having this large RTO, the application TCP timer can expire
  before the retransmission packet is sent.  The application
  timeout is considered as a major failure and is desirable to
  be avoided.

And your first reply was:

From: David Miller <davem@...emloft.net>
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)

> 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.

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.)

(2) Let TCP have a notification of some kind.

If so, I would like to explore the way to implement it.

I am interested in TCP notification now because making the
application timeouts longer in my case is just not feasible.

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