[PATCH] Add a new TCP_IGNOREIDLE socket option

[Lawrence Stewart]

On 02/08/13 07:04, George Neville-Neil wrote:
> 
> 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.

+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