[PATCH] Add a new TCP_IGNOREIDLE socket option

[George Neville-Neil]

On Feb 6, 2013, at 12:28 , Alfred Perlstein <bright at 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:
>>> 
>>> 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.

Best,
George