Many times I've heard the claim "out-of-order packets" wreak havoc with your application. Many interpretations conclude that must be because of poor application coding. Blaming others can flow both ways, it seems. My favorite comment in all threads about Duplicate ACKs and Fast Retransmit concludes with " how the network performance is improved by a server reboot. "
Back to our main concern here. When a receiver gets TCP datagrams 1,2,3 and 5 it will immediately send an ACK expecting 4 as it already did to confirm receipt of datagram 3. Ding. First 'duplicate ACK'.
Now, listen closely as I don't plan to get in this habit. The RFC for TCP Congestion Control is a moderately pain-free read and gives the authoritative fundamentals on how TCP should behave. Give it a look!
The key to dig out is somewhere around page 6. Duplicate ACKs cause sender to reduce window size. The whole mechanism and scenarios for SLOWING down transmission rates of the TCP flow are detailed.
MORAL: nothing has to be lost and TCP can still determine congestion has been encountered and slow down. Sometimes significantly. Also came across these great course slides.
No comments:
Post a Comment