[p2p-hackers] UDP file transfer link speed identification

[David Barrett]

Ahh, thank you Saikat and Michael.  I didn't put together the pieces in 
a way that made sense; now I see:

1) Because the receiver generates an ACK for every received packet, and
2) Because the ACK always requests the first missing byte, therefore
3) Out of order or dropped packets generate duplicate ACKs.

Likewise, I now understand why a timeout is more severe than a duplicate 
ACK, as a timeout indicates that *nothing* is getting through (because 
the receiver is generating no ACKs).

Furthermore, I see why picking three duplicate ACKs (ie, three ACKs 
asking for the same byte) is a good threshold as it allows the client to 
accomodate some amount of out-of-order delivery without necessarily 
requiring retransmission.

A couple followup questions:

1) Does the sender maintain a separate retransmission timer for each 
packet sent, or just one per connection?  Is this timer reset each time 
it receives any ACK (even a duplicate ACK), or only when it receives the 
"correct" ACK?

2) What's the best resource for learning more about selective ACK in use 
in the Internet today, RFC 2018?  What's the "state of the art" in 
selective ACK approaches (even if not widely deployed)?

Thanks!

-david

Saikat Guha wrote:
> On Sat, 2005-07-23 at 22:58 -0700, David Barrett wrote:
> 
>>Can you clarify for me what precisely is a "duplicate ACK"?  Specifically:
>>
>>- Does it literally mean two ACK packets that are byte-identical?  Or 
>>just two ACKs that overlap?
> 
> 
> Two inbound packets with the same # in the ACK field. 
> 
> 
> 
>>- Does the client ever send a duplicate ACK intentionally?  Or is this 
>>just something that happens occasionally on bad connections?
> 
> 
> The TCP receiver always ACK's (read: asks for) the first byte in the
> stream that it has not yet received. Say it is waiting for byte X and
> receives a packet starting with byte X+1400 ... then it will ACK/ask for
> a packet with byte X. Say the sender sends three packets starting with
> bytes X, X+1400, X+2800, X+3500 ... and the first and third packets are
> lost; the other two packets will be responded to with an ACK for X each
> -- thus making duplicate ACKs. The sender only learns that the first
> packet was lost; and that some two packets did reach the destination
> (since 2 ACKs were generated). The sender doesn't learn which packet
> other than the first one was lost. For plain old TCP, this is fine
> because the receiver doesn't queue up the packets it received since they
> are out of sequence .. and waits for the sender to retransmit them (even
> the ones that it did receive).
> 
> SACK (selective ACK) sort of rectifies this by allowing the receiver to
> tell the sender which ones were dropped, in a limited way -- kinda like
> a bitmap but not quite.
> 
> 
> Now the way regular TCP handles infers isolated losses and congestion is
> as follows:
> 
> If the sender doesn't receive an ACK for the byte it has not yet sent;
> it concludes that a loss occurred and cuts the windows to 1. 
> 
> If it receives dup ACKs, then it infers that some packets are going
> through fine and therefore there isn't a terrible lot of congestion. So
> it artificially inflates its window and keeps sending packets (at half
> the original rate instead of 1). See TCP Fast Retransmit and Fast
> Recovery [1].
> 
> 
> [1]  http://www.faqs.org/rfcs/rfc2001.html
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences