> Hi Andi, > Thanks for your comments and your help. > I'm aware to RFC 793 statement regarding to ACK. > My problem is that these piggyback ACK can cause duplicate ACK and therefor invoke the > Fast Retransmit mechanism. > Consider the following situation when the sender send TCP segment and the receiver send > ACK. > Then the sender send another 3 (or more) segments, and meanwhile it receives 3 > piggyback ACKs that have been sent by the receiver (i.e. the receive send 3 TCP frame > before it receives the 3 packets that has been sent by the Sender). > The sender can assume that these ACKs are duplicate ACK and therefor it enters into > Fast Retransmit although it shouldn't Fast retransmit is not invoked in that case, since we dont consider it a duplicate ack if it were piggybacked on data. When we process an incoming ack (regardless of fast path or slow, we end up in tcp_ack()). If the incoming frame contained data, or if the ack was a window update, and of course if the ack acknowledged new data or a SYN, we wouldnt consider it a dubious ack and wouldnt fall into some fairly complex processing that leads to fast retransmit... Are you seeing retransmissions and fast retransmits? You can look at /proc/net/netstat and see the TCPFastRetrans counter, for example, and determine if thats happening. There are some other useful counters in /proc/net/netstat that might be interesting.. Hope that helps, thanks, Nivedita - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
