From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 14:49:08 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 08F21CA6 for ; Wed, 13 Feb 2013 14:49:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C515807 for ; Wed, 13 Feb 2013 14:49:06 +0000 (UTC) Received: (qmail 44487 invoked from network); 13 Feb 2013 16:06:28 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Feb 2013 16:06:28 -0000 Message-ID: <511BA7D9.3050709@freebsd.org> Date: Wed, 13 Feb 2013 15:48:57 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lawrence Stewart 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> In-Reply-To: <511BA29E.5050501@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 13 Feb 2013 14:49:08 -0000 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. > 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. 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. > 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. >> 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 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. -- Andre