Guys you are the greats !! Thanks for your help. RamiC. P.S. I didn't see retransmission at all. It was only theoretical question. Nivedita Singhvi wrote: > > 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
