In section 6.3.3 (page 512) of the book Computer Networks: A Systems Approach, by Peterson & Davie, I found the following statement:
Given the current 64-KB maximum advertised window size, TCP’s fast retransmit mechanism is able to detect up to three dropped packets per window in practice.
My question is: why "up to" 3 dropped packets?
I think I may have sketched part of the argument, but I'm still not sure about it:
- Assume a (max. ?) MSS of 1 kB
- Assume one currently has min(congestion_wnd, advertised_wnd) = 64 kB
- I'll think of window sizes in terms of packets, so I'll consider a packet to have size 1 kB, and thus a window size of 64 packets.
Say that a TCP sender is currently transmitting a window of size 64 packets, starting at sequence number p. Say that packet p + d is dropped. We can detect the dropped packet and re-transmit it if the sender has (at least) 4 more packets to send after packet p + d (i.e. +3 subsequent packets to generate 3 duplicate ACKs + 1 re-transmission). This leaves us with 64 – 4 = 60 'slots' on which we can have dropped packets.
The cost of a dropped packet is 5 packets, i.e. the 1 dropped packet + 3 subsequent packets to get 3 duplicate ACKs + 1 re-transmission. This gives us a credit of x = 60 / 5 = 12 packets to drop, which is larger than 3.
Where is my logic failing? I'm also doubtful about the validity of my assumptions regarding packet and MSS size in byte, but the statement seems to combine (mix up?) packets and byte sizes, which may contribute to the confusion.
Thanks!
Best Answer
Based on their understanding of the Fast Retransmit algorithm, I believe the authors are giving you their real-world idea of what to expect. Understand, this is the authors' idea. Even your argument is made with some assumptions which may, or may not, be congruent with the authors' assumptions. You could contact the authors for clarification. A simple search turns up a verified e-mail address for Larry Peterson at the University of Arizona.
RFC 2581, TCP Congestion Control: