David,&nbsp;Matthew&nbsp;and&nbsp;Daniel,&nbsp;<br><br>While I agree that TCP flow control is good and all, I worry a bit about<br>the TCP high-horse&nbsp;and&nbsp;the&nbsp;many&nbsp;newbies&nbsp;who&nbsp;misunderstand&nbsp;it. Without<br>implicating anyone, it's worth pointing out that TCP&nbsp;is&nbsp;not&nbsp;sacrosanct, it 
<br>does not provide immunity from congestion, and it does not guarantee<br> fair bandwidth sharing at the host level. <br><br>I can create hundreds of TCP (or TCP-like) flows&nbsp;in parallel, easily consume more<br>than my fair share of bandwidth, and easily create congestion at the routers by 
<br>closing and creating TCP connections (slow start, anyone?).&nbsp;Many p2p apps do<br> exactly that: open many connections to many other hosts.<br><br>In fact, I'm cranky at the moment because some idiot's&nbsp;p2p&nbsp;download&nbsp;is&nbsp;consuming 
<br> all the bandwidth at my current&nbsp;wireless hotspot. Maybe what we need is to extend the TCP<br>ideas from the flow level to the host-level (and either embed them deep into the OS <br>or enforce them via&nbsp;traffic&nbsp;shaping). 
<br><br>That said, it's&nbsp;better&nbsp;to&nbsp;use&nbsp;a&nbsp;protocol&nbsp;with&nbsp;built-in&nbsp;congestion&nbsp;control&nbsp;than&nbsp;without,&nbsp;and <br> it's better to adopt TCP's flow control than either nothing or something untested at large.<br><br>Bob.<br><br>