Thanks for bearing with my questions. The RFC makes it very clear why this is bad and I agree that workarounds in the kernel for naughty apps are silly and a bad idea. I do suspect that Java wont be the only app that has issues with this. In the meantime there is a workaround.
Thanks all, Eric Molitor On 3/10/06, David S. Miller <[EMAIL PROTECTED]> wrote: > From: "Eric Molitor" <[EMAIL PROTECTED]> > Date: Thu, 9 Mar 2006 22:39:16 -0600 > > > Its pretty bad on both. But most Java developers debug via localhost. > > The slowdowns don't occur on Windows, Solaris, or the unoficial JDK > > port to BSD. But I dont know what kernels support ABC. For now I will > > see what sun does with the bug report and then chase after IBM. IBM > > tends to be more willing to fix these sorts of things in their JDK > > faster than Sun. (And for now it's probably best to say that remote > > debugging doesn't work with kernels 2.6.15 and higher due to JDK > > bug(s). For simple/small frames its slow but usable, for large frames > > its unusable.) > > The core issue is that these applications expect small frames to open > up the congestion window, and by the congestion control rules that > really should not occur. In fact, the previous code allows something > called an ACK division attack to make a sender open up the congestion > window larger than it should. > > In an ACK division attack, when you receive a frame you send back > multiple ACKs, for varying sequence number offsets within the single > frame you received. The sender will increase his congestion window > each one of these "sub-ACKs". > > ABC is strictly enforcing byte based CWND growth now. > > All the details are in RFC3465. > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
