Date: Sun, 28 Oct 2012 22:33:39 +0100 From: Andre Oppermann <andre@freebsd.org> To: Rui Paulo <rpaulo@felyko.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r242266 - head/sys/netinet Message-ID: <508DA4B3.4080002@freebsd.org> In-Reply-To: <4532DEB1-4EFE-4E4B-BE1F-A99FFC58DBA3@felyko.com> References: <201210281947.q9SJlku2085767@svn.freebsd.org> <4532DEB1-4EFE-4E4B-BE1F-A99FFC58DBA3@felyko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28.10.2012 22:03, Rui Paulo wrote: > On 28 Oct 2012, at 12:47, Andre Oppermann <andre@FreeBSD.org> wrote: > >> Author: andre >> Date: Sun Oct 28 19:47:46 2012 >> New Revision: 242266 >> URL: http://svn.freebsd.org/changeset/base/242266 >> >> Log: >> Increase the initial CWND to 10 segments as defined in IETF TCPM >> draft-ietf-tcpm-initcwnd-05. It explains why the increased initial >> window improves the overall performance of many web services without >> risking congestion collapse. >> >> As long as it remains a draft it is placed under a sysctl marking it >> as experimental: >> net.inet.tcp.experimental.initcwnd10 = 1 >> When it becomes an official RFC soon the sysctl will be changed to >> the RFC number and moved to net.inet.tcp. >> >> This implementation differs from the RFC draft in that it is a bit >> more conservative in the case of packet loss on SYN or SYN|ACK because >> we haven't reduced the default RTO to 1 second yet. Also the restart >> window isn't yet increased as allowed. Both will be adjusted with >> upcoming changes. >> >> Is is enabled by default. In Linux it is enabled since kernel 3.0. > > > Didn't you also forget to point out the problems associated with it? > > http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00 IW10 has been heavily discussed on IETF TCPM. A lot of research on the impact has been done and the overall result has been a significant improvement with very little downside. Linux has adopted it for quite some time already as default setting. The bufferbloat issue is certainly real and should not be neglected. However the solution to bufferbloat is not to send less packets into the network. In fact that doesn't even make a difference simply because other packets with take their place. Buffer bloat can only be fixed in the devices that actually do the buffering. A much discussed and apparently good approach seems to be the Codel algorithm for active buffer management. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?508DA4B3.4080002>