[PATCH] Add a new TCP_IGNOREIDLE socket option

[Andre Oppermann]

On 11.02.2013 19:56, Adrian Chadd wrote:
> On 11 February 2013 03:18, Andre Oppermann <andre at freebsd.org> wrote:
>
>> In general Google does provide quite a bit of data with their experiments
>> showing that it isn't harmful and that it helps the case.
>>
>> Smaller RTO (1s) has become a RFC so there was very broad consensus in
>> TCPM that is a good thing.  We don't have it yet because we were not fully
>> compliant in one case (loss of first segment).  I've fixed that a while
>> back and will bring 1s RTO soon to HEAD.
>>
>> I'm pretty sure that Google doesn't ignore idle on their Internet facing
>> servers.  They may have proposed a decay mechanism in the past.  I'd have
>> to check the TCPM archives for that.
>
> Argh, the "If google does, it it must be fine" argument.

Please.  You removed what I was replying to.  There is no doubt IW10
originated from Google.  However Google took it to TCPM and provided
measurement data with it.  After some forth and back they provided more
data which began to convince more people on TCPM.  Eventually the
proposal was adopted as official TCPM working group draft and likely
will become a RFC later this year.

If you want to argue against RTO1s (RFC6298) then the lead authors are
from ICSI/UC Berkeley.  Google did participate in that one by providing
additional measurement data.

> Does Google publish the data for these experiments with the
> international and local links broken down?

Yes.  Have you followed the evolution and discussion of IW10 on TCPM?

> Google run a highly distributed infrastructure (this isn't news for
> anyone, I know) and thus the link distance, RTT, number of hops, etc
> may not accurately reflect "the internet". It may accurately reflect
> "the internet from the perspective of being roughly within the same
> city or state" in a lot of cases.
 >
> The TCP congestion algorithms aren't just for avoiding congestion over
> a peering fabric and last-mile ISP infrastructure.

IW10 is not a congestion control algorithm.  It is a change to the
initial state of it at the beginning of an connection when not much
other data is available.  Many years ago the same thing happend with
RFC3390 which increased the IW to 3 segments.

> The effects of tweaking congestion algorithms for delivery over a
> local peering infrastructure where you try to run things as
> un-congested as possible (where congestion is now The ISPs Problem)
> where you maintain tight control over as much of the network
> infrastructure as you can is likely going to be very different to the
> congestion algorithm behaviour needed for some end-node speaking to a
> variety of end-nodes over a longer, more varying set of international
> links. You know, what TCP congestion algorithms are also trying to
> "play fair" with.

I agree but not relevant to this case.

> Please - as much as I applaud Google for what they do, please don't
> generalise their results to "the greater internet" without looking at
> the many caveats/assumptions.

Well, that's exactly what I'm trying to do here.  Except not only for
ideas sourced from Google but also other places.  Like "it's in Linux
and the Internet hasn't broken down yet".  Without any measurement
date whatsoever.

-- 
Andre