[p2p-hackers] UDP file transfer link speed identification

[Michael Parker]

David,

Because TCP data can take different paths between a single source and 
destination, TCP packets may arrive out-of-order at the destination. Now 
TCP usually maintains a timer for each packet sent (usually set to the 
RTO); if it has not received an ACK for that packet's sequence number by 
the time this timer expires, it retransmits the packet. But in reality, 
this is naive, and causes too long a delay for lost packets. Say the 
sender sends TCP packets X-1, X, X+1, X+2, X+3, ... X+n. The receiver 
gets packet X-1, and acknowledges X-1. The receiver next receives X+1, 
instead of X as expected, so it buffers packet X+1 but actually 
acknowledges X-1 -- the last _cumulative, in-order_ packet it has 
received. This causes a duplicate X-1 at the sender, who can come to two 
conclusions: packet X experienced extra delay and so it is simply going 
to arrive out of order, or it was dropped in the network and requires 
retransmission. If it were pessimistic, it would assume the latter and 
retransmit immediately. By adopting a "3 duplicate ACK" policy, it 
instead takes a wait-and-see attitude. If the receiver gets X+2 next, it 
again buffers this packet and acknowledges X-1. This causes another 
duplicate ack at the sender, which again decides whether to retransmit 
packet X or not. If the sender declines to retransmit, and the receiver 
then received X, it now acknowledges X+2, since all packets up to and 
including X+2 have been received. When the sender receives this 
acknowledgment, it knows X has been received, and so it can cancel the 
timer for packet X.

So, as you can see, the 3 duplicate ACK rule (empirically derived?) is 
just the threshold between the sender deciding that the packet is simply 
arriving out-of-order, and deciding it was lost and thus requiring 
retransmission. The gritty details of this might be wrong, but I'm 
pretty sure that's the gist of it.

- Mike


David Barrett wrote:

> Daniel Stutzbach wrote:
>
>> If a loss is detected via 3 duplicate ACKs, cwnd and ssthresh are both
>> cut in half, then it goes into Fast Retransmit mode to recover the
>> loss.  Once the loss is recovered, it returns to congestion avoidance
>> mode.
>
>
> 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?
>
> - Does the client ever send a duplicate ACK intentionally?  Or is this 
> just something that happens occasionally on bad connections?
>
> Basically, I just don't "get" what duplicate ACKs are, why I should 
> switch fast transmit in response to three of them in a row (does this 
> mean six identical ACK packets?), and so forth.  Can you shed any 
> light on this for me?
>
> Thanks!
>
> -david
> _______________________________________________
> 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
>