<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Mar 18, 2014, at 7:09 PM, Tony Arcieri <<a href="mailto:bascule@gmail.com">bascule@gmail.com</a>> wrote:<div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Flood the weakest link with TCP traffic, and it will drop your UDP packets on the floor.</div><div><br></div><div>Improvement? </div></div><div><br></div><div>Does this instill confidence in the protocol's availability?</div>
<div><br></div><div><a href="http://www.delaat.net/rp/2010-2011/p48/report.pdf">http://www.delaat.net/rp/2010-2011/p48/report.pdf</a><br></div></div></div></blockquote>TCP - and more particularly bad TCP flow/congestion control mechanisms - are well on their way to rendering the Internet sclerotic. It's an unwritten (though there are written hints) rule that any proposal for a new Internet protocol will not be accepted by the IETF unless it's "TCP friendly" - code for "doesn't screw up even old and stupid TCP flow control mechanisms". While the rule is more or less political, there is significant reality behind it, as the experience of those who've violated "TCP-friendliness" has shown: The problem is often not so much that the new protocol interferes with TCP as that TCP interferes with the new protocol. Since so many components are optimized to make TCP as it currently exists work well, it should not be surprising that the new guys always get beaten up.</div><div><br></div><div>It's a long and messy story, with techno-political biases way, way back (when it was decided that packet loses were good enough to do flow control and that doing anything more was unnecessary complexity). There are old, old papers showing that this would eventually cause all kinds of instabilities and other problems, but during the long golden era when link speeds and installed capacity kept way ahead of demand they were held at bay. We'd fallen off the room, but as we passed window after window, we could keep saying "we're fine so far". That golden era ended a couple of years back, and the old predictions of an impending crash into the sidewalk are starting to seem a bit more real.</div><div><br></div><div>Anyway: Crafting a new protocol to run alongside TCP (TCP will be around indefinitely, and no matter what will be the dominant form of traffic for years to come) is an extremely difficult problem. No solutions are apparent right now. CurveCP was an elegant attempt, and the designers even tried to account for interactions with TCP; but apparently they failed. CurveCP on a "pure" network, without a dominant presence of TCP - probably very nice. But no one's going to run it that way.</div><div><br></div><div><div> -- Jerry</div><div><br></div></div><br></body></html>