linux-kernel - Re: Feedback on 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] [day] [month] [year] [list]

Message-Id: <20080616.234352.56004956.noboru.obata.ar@hitachi.com>
Date:	Mon, 16 Jun 2008 23:43:52 +0900 (JST)
From:	Noboru OBATA <noboru.obata.ar@...achi.com>
To:	davidn@...idnewall.com
Cc:	davem@...emloft.net, linux-kernel@...r.kernel.org,
	linux-net@...r.kernel.org, noboru.obata.ar@...achi.com
Subject: Re: Feedback on TCP: Make TCP_RTO_MAX a variable

> Last year, Obata Noboru sent a patch to permit adjustment of
> TCP_RTO_MAX, which I have found useful.  Refer to
> http://marc.info/?l=linux-netdev&m=118422471428855 for details.
> 
> A customer reported that their internet-connected POS terminals were
> regularly "freezing" for extended periods, sometimes for as long as a
> few minutes.  My analysis, such as it was, suggested that those
> occasions were caused by floods of packets directed towards the internet
> link at one end or the other (i.e. POS terminal or central server),
> leading to severe packet loss and maximum packet retransmit times during
> which no session data could be transmitted.  I believe those floods were
> caused by anonymous third parties scanning the internet, and attempting
> to break through my client's routers.  I also believe that to be an
> unavoidable social quality of the internet; I have to live with it.

I found your feedback interesting, David.

The wireless people gave me an similar feedback when I first
post the patch.  They said my patch helps TCP connections
recover from the bursty loss much faster than the normal TCP
behavior.  They found my patch useful because a packet loss on
wireless is not necessarily caused by link congestion, but
largely by temporary radio noize or handover between base
stations.

Your situtation seems to me that your connection itself does not
contribute the congestion, but other bursty incoming traffic
does.  So exponential back-off does not help the packet loss
substantially.

My motivation of the patch is different, however.  I wanted TCP
to retransmit the packet shortly after the failover of
underlying network.

I found it interesting that in all the cases where my patch
helps people, the TCP connection in question is not really a
part of congestion and has nothing to do with the packet loss
the connetion is experiencing.

Regards,

-- 
Noboru OBATA (noboru.obata.ar@...achi.com)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/