[PATCH] Add a new TCP_IGNOREIDLE socket option

Adrian Chadd adrian at freebsd.org
Mon Feb 11 18:56:05 UTC 2013


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.

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

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.

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.

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.



Adrian


More information about the freebsd-net mailing list