Date: Thu, 7 Feb 2013 15:04:08 -0500 From: George Neville-Neil <gnn@neville-neil.com> To: Alfred Perlstein <bright@mu.org> Cc: Randall Stewart <rrs@lakerest.net>, John Baldwin <jhb@freebsd.org>, net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Message-ID: <E6BF2B74-175F-49D9-B480-8941294D2E19@neville-neil.com> In-Reply-To: <511292C9.4040307@mu.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 6, 2013, at 12:28 , Alfred Perlstein <bright@mu.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E6BF2B74-175F-49D9-B480-8941294D2E19>