From owner-freebsd-net@FreeBSD.ORG Thu Feb 7 20:04:03 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D97859B1; Thu, 7 Feb 2013 20:04:03 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA46A75; Thu, 7 Feb 2013 20:04:03 +0000 (UTC) Received: from [38.105.238.108] (port=54565 helo=[10.7.1.235]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U3XhQ-0005dY-PZ; Thu, 07 Feb 2013 15:04:00 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: George Neville-Neil In-Reply-To: <511292C9.4040307@mu.org> Date: Thu, 7 Feb 2013 15:04:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: Randall Stewart , 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, 07 Feb 2013 20:04:03 -0000 On Feb 6, 2013, at 12:28 , Alfred Perlstein wrote: > On 2/6/13 4:46 AM, John Baldwin wrote: >> On Wednesday, February 06, 2013 6:27:04 am Randall Stewart wrote: >>> John: >>>=20 >>> A burst at line rate will *often* cause drops. This is because >>> router queues are at a finite size. Also such a burst (especially >>> on a long delay bandwidth network) cause your RTT to increase even >>> if there is no drop which is going to hurt you as well. >>>=20 >>> A SHOULD in an RFC says you really really really really need to do = it >>> unless there is some thing that makes you willing to override it. It = is >>> slight wiggle room. >>>=20 >>> In this I agree with Andre, we should not be *not* doing it. = Otherwise >>> folks will be turning this on and it is plain wrong. It may be fine >>> for your network but I would not want to see it in FreeBSD. >>>=20 >>> In my testing here at home I have put back into our stack max-burst. = This >>> uses Mark Allman's version (not Kacheong Poon's) where you clamp the = cwnd at >>> no more than 4 packets larger than your flight. All of my testing >>> high-bw-delay or lan has shown this to improve TCP performance. This >>> is because it helps you avoid bursting out so many packets that you = overflow >>> a queue. >>>=20 >>> In your long-delay bw link if you do burst out too many (and you = never >>> know how many that is since you can not predict how full all those >>> MPLS queues are or how big they are) you will really hurt yourself = even worse. >>> Note that generally in Cisco routers the default queue size is = somewhere between >>> 100-300 packets depending on the router. >> Due to the way our application works this never happens, but I am = fine with >> just keeping this patch private. If there are other shops that need = this they >> can always dig the patch up from the archives. >>=20 > This is yet another time when I'm sad about how things happen in = FreeBSD. >=20 > A developer come forward with a non-default option that's very useful = for some specific workloads, specifically one that contributes much time = and $$$ to the project and the community rejects the patches even though = it's been successful in other OSes. >=20 > It makes zero sense. >=20 > John, can you repost the patch? Maybe there is a way to refactor this = somehow so it's like accept filters where we can plug in a hook for TCP? >=20 > I am very disappointed, but not surprised. >=20 I take away the complete opposite feeling. This is how we work through = these issues. It's clear from the discussion that this need not be a default in the = system, and is a special case. We had a reasoned discussion of what would be = best to do and at least two experts in TCP weighed in on the effect this change = might have. Not everything proposed by a developer need go into the tree, in = particular since these discussions are archived we can always revisit this later. This is exactly how collaborative development should look, whether or = not the patch is integrated now, next week, next year, or ever. Best, George