netdev - Re: [PATCH] tcp: Expose the initial RTO via a new sysctl.

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:	Fri, 20 May 2011 03:27:37 -0700
From:	"H.K. Jerry Chu" <hkjerry.chu@...il.com>
To:	Hagen Paul Pfeifer <hagen@...u.net>
Cc:	David Miller <davem@...emloft.net>, tsunanet@...il.com,
	kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org,
	yoshfuji@...ux-ipv6.org, kaber@...sh.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tcp: Expose the initial RTO via a new sysctl.

On Wed, May 18, 2011 at 1:20 PM, Hagen Paul Pfeifer <hagen@...u.net> wrote:
> * David Miller | 2011-05-18 15:52:00 [-0400]:
>
>>I've already changed the initial TCP congestion window in Linux to 10
>>without some stupid draft being fully accepted.
>>
>>I'll just as easily accept right now a patch right now which lowers
>>the initial RTO to 1 second and adds the 3 second RTO fallback.
>
> I like the idea to make the initial RTO a knob because we in a isolated MANET
> environment have a RTT larger then 1 second. Especially the link layer setup
> procedure over several hops demand some time-costly setup time. After that the
> RTT is <1 second. The current algorithm works great for us. So this RTO change
> will be counterproductive: it will always trigger a needless timeout.
>
> The main problem for us is that Google at all pushing their view of Internet
> with a lot of pressure. The same is true for the IETF IW adjustments, which is
> unsuitable for networks which operates at a bandwidth characteristic some
> years ago. The _former_ conservative principle "TCP over everything" is
> forgotten.

Not sure how our various parameter tuning proposals deviate from the "TCP over
everything" principle?

Note that the design goal of rfc2988bis is to try to benefit 98% of
traffic while
keeping any negative impact to the remaining 2% at a minimum. This is why we
limit the use of < 3sec initRTO to at most once. This way the negative impact
of the 1sec initRTO to a path with RTT > 1sec is limited mostly to one
additional,
small, spuriously retransmitted SYN or SYN-ACK pkt, and the unnecessary
reduction of IW to 1 segment.

We actually thought about removing the IW reduction part but unfortunately the
text belongs to a different rfc5681, which is at a higher maturity
level ("draft-standard")
than rfc2988 hence can't be done as part of rfc2988bis. Anyway I have
since added
the recommendation to the IW10 draft. See draft-ietf-tcpm-initcwnd-01.txt.

The bottom line is the damage of rfc2988bis to any network with
initRTT > 1sec is
limited to one spurious retransmitted SYN/SYN-ACK. In the current Linux code,
the SYN/SYN-ACK retransmit is forgotten on the passive open side by the time
3WHS is completed so there is nothing needed to be done. But for the active
open side SYN retransmit will cause not long IW to be reduced to 1, but also
reduction of ssthresh, which is not part of rfc5681 so some more work is needed.
I can provide a patch (or work with tsuna) to ensure a correct fix is made.

Jerry

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