From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 01:46:55 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 A5DFE2F3; Wed, 20 Feb 2013 01:46:55 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB8988C; Wed, 20 Feb 2013 01:46:54 +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 43F047E81E; Wed, 20 Feb 2013 12:46:46 +1100 (EST) Message-ID: <51242B05.1040003@room52.net> Date: Wed, 20 Feb 2013 12:46: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: Andre Oppermann 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> In-Reply-To: <511C3FB8.40506@freebsd.org> 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: John Baldwin , 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 01:46:55 -0000 *crickets chirping* Time to move this discussion forward... On 02/14/13 12:36, Lawrence Stewart wrote: > On 02/14/13 01:48, Andre Oppermann wrote: >> On 13.02.2013 15:26, Lawrence Stewart wrote: >>> On 02/13/13 21:27, Andre Oppermann wrote: >>>> On 13.02.2013 09:25, Lawrence Stewart wrote: >>>>> The idea is useful. I'd just like to discuss the implementation >>>>> specifics a little further before recommending whether the patch should >>>>> go in as is to provide a stop gap, or we rework the patch to be a >>>>> little >>>>> less specific in readiness for the future work I have in mind. [snip] >>> We could initially map "low delay at all costs" to a TCP stack meaning >>> of "disable idle window reset" and expand the meaning later (e.g. >>> relaxing the silly window checks as briefly discussed in the other >>> thread). >> >> Ugh, if you go that far fork it, obtain a fresh protocol number and don't >> call it TCP anymore. > > You're channelling Joe Touch ;) > > What exactly is TCP? As far as interop is concerned, it's just a wire > protocol - as long as I format my headers/segments correctly and ignore > options I don't understand, I can communicate with other TCP stacks, > many of which implement a different set of TCP features and options. > > The dynamics of the protocol have evolved significantly over time and > continue to do so because of its ubiquity - it flows freely across the > public internet and gets used for all manner of things it wasn't > initially designed to handle (well). A lot of the dynamics are also > controlled by optional parameters. > > So no, we don't need a new protocol number. We need to provide knobs > that allow people to tune TCP dynamics to their particular use case. [snip] >>> We need to figure out how to provide the functionality in FreeBSD >>> proper, and a CC module is not the answer. >> >> I totally disagree. This functionality (removal) is not at all a part >> of TCP and should not be supported directly. > > I don't understand how you can argue that idle window resetting is an > intrinsic and non negotiable part of TCP. There is no one true set of > options and features that is TCP. It is not only one idea. > > Let's work on providing a rich set of knobs to tune every aspect of our > TCP stack's dynamics and operation that don't break wire format, set > conservative defaults and document everything thoroughly. 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. - 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). - 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. Thoughts? Cheers, Lawrence