BitTorrent uTP uTorrent Transport Protocol ACK policy (BEP29)
<p>I'm writing a Boost version of the <a href="http://www.bittorrent.org/beps/bep_0029.html" rel="nofollow">BitTorrent uTorrent Transport Protocol</a> (a buffer-sensitive reliable stream protocol built on UDP datagrams).  My goal is to have a UDP-socket manager that sends &amp; receives datagrams and manages all the congestion &amp; error control for many uTP connections.  Client threads can create new uTP connections by saying <code>utp_manager.async_connect( endpoint )</code> or accept inbound connections by saying <code>utp_manager.async_accept( handler )</code></p>

<p>The uTP specification is a bit thin, and I don't see how to handle ACK numbers in a case such as:</p>

<pre><code>DATA (seq=1) ----------------&gt; received OK
                     X-------- ACK=1 (not received)
DATA (seq=2) ----------------&gt; received OK
             &lt;---------------- ACK=2 (received OK)
</code></pre>

<p>Does the sender treat DATA-1 as ACK'd because it received ACK=2?  Or will it re-send DATA-1?  In that case, will the recipient send ACK=1, even though it has already ACK'd 2?</p>

<p>I think the rules need to be: </p>

<ol>
<li>Recipient always sends ACK for the highest <em>continuous</em> SEQ_NR it has received (not the SEQ_NR of the last packet it received, as the spec states)</li>
<li>Sender can assume that <em>all</em> packets up to ACK_NR have been received (plus any selective-ACK packets) even if one ACK isn't received (as in my example above)</li>
<li>If there are any gaps at the receiver, it will keep ACKing the SEQ_NR of the last packet received before the first missing packet (plus any selective-ACK that it does).</li>
<li>Sender retransmits the packet at ACK_NR + 1 when it receives 3 duplicate ACKs or when 3 packets after ACK_NR have been ACK'd with selective-ACK).</li>
</ol>

<p>I know I could try to set these scenarios up and run them against an existing implementation, but I don't think there are any reference implementations that are guaranteed to be correct, and it's tedious to set things up.  I'm hoping somebody who has studied or implemented the protocol will be able to say if I've gotten it right, or what I'm missing.</p>