<br><br><div><span class="gmail_quote">On 4/1/06, <b class="gmail_sendername">Matthew Kaufman</b> <<a href="mailto:matthew@matthew.at" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">matthew@matthew.at
</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Forward error correction has its place, but it is no excuse for eliminating<br>the feedback necessary to perform proper congestion control. </blockquote><div><br>I agree. I suggested getting rid of resends and selective acks via coding,
<br>not ditching congestion control altogether. Coding can get rid of ack <br>packets that often carry just a tiny bit of information. And it solves his<br> problem of what resend timeout parameters to pick. We know too little
<br>about Lemon's system to jump to any conclusions about congestion<br>control - for all I know, it's a point-to-multipoint system with built-in<br>throttling. <br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
My personal (albeit biased) suggestion is to use amicima's MFP, which gets<br>you congestion controlled delivery for both reliable *and* unreliable flows,<br>among many other features.</blockquote><div><br>Sounds cool, does it work on Linux?
<br></div></div><br>Bob.<br>