[p2p-hackers] UDP file transfer link speed identification

[Saikat Guha]

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

-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050723/3f7210b0/attachment.pgp