Date: Wed, 20 Feb 2013 12:46:45 +1100 From: Lawrence Stewart <lstewart@room52.net> To: Andre Oppermann <andre@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Message-ID: <51242B05.1040003@room52.net> In-Reply-To: <511C3FB8.40506@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
*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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51242B05.1040003>