Date: Wed, 06 Feb 2013 09:28:41 -0800 From: Alfred Perlstein <bright@mu.org> To: John Baldwin <jhb@freebsd.org> Cc: Randall Stewart <rrs@lakerest.net>, net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Message-ID: <511292C9.4040307@mu.org> In-Reply-To: <201302060746.43736.jhb@freebsd.org> References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511292C9.4040307>