From owner-freebsd-net@FreeBSD.ORG Fri Feb 22 01:40:54 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C5C0285; Fri, 22 Feb 2013 01:40:54 +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 8EEC1BDE; Fri, 22 Feb 2013 01:40:53 +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 5F6547E824; Fri, 22 Feb 2013 12:40:45 +1100 (EST) Message-ID: <5126CC9D.9010409@freebsd.org> Date: Fri, 22 Feb 2013 12:40:45 +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> <51244A0C.8000800@freebsd.org> 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: Fri, 22 Feb 2013 01:40:54 -0000 On 02/21/13 20:20, Sepherosa Ziehau wrote: > On Wed, Feb 20, 2013 at 11:59 AM, Lawrence Stewart wrote: >> 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. > > Yeah, I would suggest the same. > >> >>>> - 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? > > I suggest using route metrics in addition to the global sysctls; Agreed. > route metrics take precedence over global sysctls. Agreed. > I don't object the per-socket settings though. However, IMHO, these > options (IW10 and ignoring idle restart, and probably others) are > administrative, so applications probably should not mess with them. Messing with individual options like IW10 on a per-socket basis is definitely in the "generally should not" basket, but I would not want to stop an application from doing so subject to the option being specified by the administrator in the net.inet.tcp.nonstandard.allowed option list. What I expect applications would want to do more frequently is hint the socket with a higher level goal e.g. "I want maximum throughput", "I want low latency", etc. This can come later though. I think we have enough agreement on the basic infrastructure to move forward at this point with some patches. I would initially like to get the basic sysctl infrastructure to support all this sorted, then look at supporting these options as route metrics, and finally look at the higher level API. Anyone else with further input, please speak up! Cheers, Lawrence