On Fri, 10 Mar 2006 09:31:19 -0800 Rick Jones <[EMAIL PROTECTED]> wrote:
> Eric Molitor wrote: > > 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. > > But if X isn't naughty is Java naughty here? > > >>>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. > > And here I thought the initial VJ congestion control stuff was doing > conservation of packets and not conservation of bytes, and conservation > of bytes was merely a shortcut for stacks that didn't track segments :) > > >>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". > > Have there been actual stacks with ack division in them? > > >> > >>ABC is strictly enforcing byte based CWND growth now. > >> > >>All the details are in RFC3465. > > Has its classification changed from experimental yet? > > What has me perplexed is say Java did stop setting TCP_NODELAY - it > wouldn't be sending any more bytes than it was before. Would it be > receiving fewer ACK's than it was before? > > rick jones Part of the issue is that NODELAY has dual meaning. It means don't delay acks (on receiver), and don't coalesce writes (on sender). If java didn't turn on NODELAY, it would get coalescing but it would then get delayed acks. If you look at the packet flow, it is the typical RPC style flow and actually would benefit from delayed acks as well. The ACK would piggyback on the response to the initial request and that would give better performance. X is different because, it is not request/response based. The mouse moves you want the packet to be sent. Something is painted, you want it displayed. Delayed ack's would only slow perceived response. - 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
