Date: Sun, 28 Oct 2012 23:25:10 +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: <508DB0C6.5050902@freebsd.org> In-Reply-To: <8CE1596C-A1E2-49BA-985D-D4D6C891C544@felyko.com> References: <201210281947.q9SJlku2085767@svn.freebsd.org> <4532DEB1-4EFE-4E4B-BE1F-A99FFC58DBA3@felyko.com> <508DA4B3.4080002@freebsd.org> <8CE1596C-A1E2-49BA-985D-D4D6C891C544@felyko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28.10.2012 22:44, Rui Paulo wrote: > 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. Then please raise your points on TCPM. >> 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. That's always the case. Reality is that the majority of links these days is very fast compared to twenty years ago. We can afford to be a bit more aggressive here. Otherwise taking your point to the extreme would mean that IW can only ever be 1 MSS. Then there is the unfairness of low RTT to high RTT transfers. But that's inherent in any end to end feedback system. >> 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? :-) I'm looking into how the whole interface stuff including ALTQ can be improved in an SMP world. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?508DB0C6.5050902>