From owner-freebsd-net@FreeBSD.ORG Thu Feb 14 01:36:59 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 8DE9DC20; Thu, 14 Feb 2013 01:36:59 +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 EF9BBCF2; Thu, 14 Feb 2013 01:36:58 +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 0D5DD7E81E; Thu, 14 Feb 2013 12:36:57 +1100 (EST) Message-ID: <511C3FB8.40506@freebsd.org> Date: Thu, 14 Feb 2013 12:36:56 +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> In-Reply-To: <511BA7D9.3050709@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: Thu, 14 Feb 2013 01:36:59 -0000 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. >>> >>> Again I'd like to point out that this sort of modification should >>> be implemented as a congestion control module. All the hook points >>> are already there and can readily be used instead of adding more special >>> cases to the generic part of TCP. The CC algorithm can be selected per >>> socket. For such a special CC module it'd get a nice fat warning that >>> it is not suitable for Internet use. >> >> As a local hack, sure, a CC module would do the job assuming you were >> happy to use a single algorithm as the base. John's patch transcends the >> algorithm in use on a particular connection, so it has wider >> applicability than a CC module. > > The algorithm is becoming somewhat meaningless when your goal is to > have an open pipe and push data as fast as possible without regard > to other traffic. NewReno, Cubic and what have you is becoming > meaningless. But that's not the goal. We're not discussing unbounded or unreactive congestion windows. If a burst causes drops, we still back off. The algorithm does still matter. >> I would also strongly oppose the inclusion of such a module in FreeBSD >> proper - it's the wrong way to implement the functionality. The patch as >> posted is technically appropriate, though I'm interested in discussing >> whether the public API should be tweaked to capture higher level goals >> instead e.g. "low delay at all costs" or "maximum throughput". > > I strongly disagree. The patch is a hack. I agree it's hacky in its current form, but for different reasons to you as outlined in my previous email. You are arguing that idle window resetting is an intrinsic and non negotiable part of TCP. This is demonstrably not true. As long as something doesn't change the wire format, then it is fair game for being tunable. How we make something tunable and what we set as defaults are where we need to be conservative. > From the description John gave on his use-case I read that he would actually take more than just > ignoring idle-cwnd-reset. And actually if I were in his situation I > would use a very aggressive congestion control algorithm doing away with > more than idle-cwnd-reset. Congestion control is only one aspect of what we're discussing. >> 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. >>> Additionally I speculate that for the use-case of John he may also be >>> willing to forgo congestion avoidance and always operate in (ill-named) >>> "slow start" mode. With a special CC module this can easily be tweaked. >> >> John already has the functionality he needs in this local tree - this >> discussion is no longer about John per se, but rather about other people >> who may want the functionality John has implemented. > > That's what I'm worried most about. So far no real "other people" have > spoken out, only cheering from the sidelines. We surely don't need them to speak out explicitly - the use case is not obscure enough that I am having difficulty imagining other places it would be useful. >> 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. Cheers, Lawrence