Date: Sun, 28 Oct 2012 14:44:21 -0700 From: Rui Paulo <rpaulo@felyko.com> To: Andre Oppermann <andre@FreeBSD.org> 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: <8CE1596C-A1E2-49BA-985D-D4D6C891C544@felyko.com> In-Reply-To: <508DA4B3.4080002@freebsd.org> References: <201210281947.q9SJlku2085767@svn.freebsd.org> <4532DEB1-4EFE-4E4B-BE1F-A99FFC58DBA3@felyko.com> <508DA4B3.4080002@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Oct 2012, at 14:33, Andre Oppermann <andre@FreeBSD.org> wrote: > 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. I have followed the discussions at tcpm, but I did not find any = conclusive evidence of the benefit of IW10. I'm sure it can help in = multiple situations but, as always, there are tradeoffs. Section 6 of = draft-ietf-tcpm-initcwnd never convinced me. > 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. Right, my point is that sending more packets in an already congested = link will negatively affect the throughput / latency of the network. I'm = not saying that it won't help you download a YouTube video faster, but = the overall fairness of TCP will be reduced. > 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. Are you working on CoDel? :-) Regards, -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CE1596C-A1E2-49BA-985D-D4D6C891C544>