svn commit: r232345 - user/andre/tcp_workqueue/sys/netinet

[Andre Oppermann]

On 02.03.2012 10:45, Ivan Voras wrote:
> On 1 March 2012 18:53, Andre Oppermann<andre at freebsd.org>  wrote:
>
>> I'm a bit wary of abuse by non-clueful enough people who think bigger
>> must be better.  There was a recent discussion to this effect on TCPM.
>> Also there were reports of congestion collapse in some networks, due
>> to some other issues.  I've even seen botched windows servers that
>> respond with an icwnd of 64K.
>>
>> Hence I'd rather not have it open to anyone to fumble with this important
>> parameter.  The (negative) effects are not directly visible to a normal
>> admin.
>
> AFAIK the whole idea about increasing the initial window was started
> in Google; there are some blog posts from their engineers and at least
> one paper (http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf).
> The reason why they have been able to experiment with it is that it's
> so easy to change in Linux:

The ease of changing it in Linux actually doesn't have anything to
do with it.  Their bonus (the network stack team) depends on making
go things faster.  They even said so on the TCPM list.  Whether it
was easy in Linux didn't really matter as Linux is their OS of choice
and hacking the whole kernel would have been acceptable as well.

To their credit they didn't just increase some tuneables but also
did the hard empirical work behind it to show that it improves what
they care about (easy) while at the time that it doesn't seem to hurt
the other TCP connections not doing it too much and that the packet
loss ratio is just slightly increased but still within the statistical
noise.

There was a great comment on HN recently:

"TL;DR version - another new guy discovers TCP slow start, and not doing it,
  wow major speedup! Now, imagine the whole Internet doing that, whoops.

  I once peevishly pointed out that if you weren't required to stop at stop
  signs your commute would go faster, but if nobody was required to stop at
  stop signs it would be slower because every other intersection would have
  an accident blocking the way.

  This is also very much true of TCP congestion control algorithms. And while
  a few people not using them can get away with it, everyone not using them
  and you will find your network latency goes from a median with a low
  standard deviation, to a slightly lower median with a HUGE standard deviation.
  ..."
http://news.ycombinator.com/item?id=3651106

If you look at RFC793 there is no mentioning of slow start or such. It
took a bit of time until John Nagle wrote RFC896 describing the effects of
unhindered data sending leading to the introduction of slow start and AIMD.

I'm wary on having every other Jon Doe doing his own "research" on the
most optimal icwnd from his point of view.

-- 
Andre

> " the initial congestion window is configured using the intitcwnd
> option in the ip route command. "
>
> So, by not having this as tunable, that opportunity was missed by
> someone who uses FreeBSD (Yahoo?). Less power to tinker results in
> less power to do some innovation.
>
> Even more, the quote I've pasted from the paper suggests it's a
> per-route setting in Linux.