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
-
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
