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]

Message-ID: <BANLkTimqtjskX5q2ovTp_c05MdqBDOWsRg@mail.gmail.com>
Date:	Tue, 31 May 2011 07:48:09 -0700
From:	tsuna <tsunanet@...il.com>
To:	"H.K. Jerry Chu" <hkjerry.chu@...il.com>
Cc:	Hagen Paul Pfeifer <hagen@...u.net>,
	David Miller <davem@...emloft.net>, 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 Fri, May 20, 2011 at 5:06 PM, H.K. Jerry Chu <hkjerry.chu@...il.com> wrote:
> Yep, that's why we've had a knob for this for years.

I was traveling last week so sorry for not replying earlier to various
comments people made.

I talked to Jerry and he's agreed to share some patches that Google
has been using internally for years.  I started this work because
after leaving Google and taking these changes for granted, I was
surprised to find that they weren't actually part of the mainline
Linux kernel.

It seems that David is willing to accept a change that will lower the
initRTO to 1s (compile-time constant), with a fallback to 3s
(compile-time constant), as per the draft rfc2988bis.  Others are
legitimately worried about the impact this would cause in environments
where RTT is typically (or always) in the 1-3s range.  Some would like
to see this as a per-destination thing.

Personally what I think would be ideal would be:
  1. A sysctl knob for initRTO, to allow people to adjust this
appropriately for their environment.
  2. Apply the srtt / rttvar seen on previous connections to new connections.

Does that sound reasonable?

For 2), I'm not sure how the details would work yet, I believe the
kernel already has what's necessary to remember these things on a per
peer basis, but it would be nice if I could specify things like "for
10.x.0.0/16 (local datacenter) use this aggressive setting, for
10.0.0.0/8 (my internal backend network) use that, for everything else
(Internets etc.) use the default".

-- 
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.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