From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 13:46:27 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 DDC5E829; Wed, 13 Feb 2013 13:46:27 +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 70DC02DB; Wed, 13 Feb 2013 13:46:27 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 84DC47E81E; Thu, 14 Feb 2013 00:46:24 +1100 (EST) Message-ID: <511B9930.8020503@freebsd.org> Date: Thu, 14 Feb 2013 00:46:24 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: George Neville-Neil Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option 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> In-Reply-To: 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: Alfred Perlstein , 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: Wed, 13 Feb 2013 13:46:27 -0000 On 02/08/13 07:04, George Neville-Neil wrote: > > 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: >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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. >>> >> This is yet another time when I'm sad about how things happen in FreeBSD. >> >> 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. >> >> It makes zero sense. >> >> 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? >> >> I am very disappointed, but not surprised. >> > > 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. +1 Whilst I would argue that some red herrings have been put forward in this thread, its progression is far from disappointing IMO. This is a sensitive area that requires careful scrutiny, independent of what our peers working on other OSes have decided is best for them. Cheers, Lawrence