From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 03:59:11 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD2E76B4; Wed, 20 Feb 2013 03:59:11 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 70CE3DE9; Wed, 20 Feb 2013 03:59:11 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id D60707E824; Wed, 20 Feb 2013 14:59:08 +1100 (EST) Message-ID: <51244A0C.8000800@freebsd.org> Date: Wed, 20 Feb 2013 14:59:08 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130213 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sepherosa Ziehau Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org> <511BA7D9.3050709@freebsd.org> <511C3FB8.40506@freebsd.org> <51242B05.1040003@room52.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Andre Oppermann , John Baldwin , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:59:11 -0000 Hi Sephe, On 02/20/13 13:37, Sepherosa Ziehau wrote: > On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart wrote: >> *crickets chirping* >> >> Time to move this discussion forward... >> >> >> If any robust counter-arguments exist, now is the time for us to hear >> them. I haven't read anything thus far which convinces me that we should >> not provide knobs to tune our stack's dynamics. >> >> In the absence of any compelling counter-arguments, I would like to >> propose the following: >> >> - We rename the net.inet.tcp.experimental sysctl node introduced in >> r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the >> initcwnd10 sysctl under this node. I should also add that I think initcwnd10 should be changed to initcwnd and take the number of segments as a value. >> - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable >> and default it to 0. Only when it is changed to 1 will we allow starkly >> non standards compliant behaviour to be enabled in the stack. As a more >> complex but expressive alternative, we can make the sysctl take a bit >> mask or CSV string which specifies which non-standard options the sys >> admin permits (I'd prefer this as we can easily test non-standard >> options like IW10 in head without blanket enabling all non standard >> behaviour). To be clear, my proposal is that specifying an allowed option in net.inet.tcp.nonstandard.allowed would not enable it as the default on all connections, but would allow the per-application mechanism we define to set the option. Setting net.inet.tcp.nonstandard.option_x to 1 would enable the option as default for all connections. >> - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl >> variable, and use it to enable/disable window-reset-after-idle behaviour >> as proposed by John. >> >> - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a >> more generic sockopt and/or mechanism for per-application tuning of all >> options which affect stack dynamics (both standard and non-standard >> options). I'm open to suggestions on what this could/should look like. > > Lawrence, > > A route metric? BTW, as for IW10, it could also become a route metric > (as proposed by the draft author's presentation > http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf) Are you suggesting having the ability to set knobs as route metrics in addition to sysctl and a per-app mechanism? If so then I am very much in favour of this. Assuming an option has been allowed in net.inet.tcp.nonstandard.allowed, it should be able to be set by an application or on a route, perhaps with a precedence hierarchy of app request trumps route metric trumps system default setting? Cheers, Lawrence