> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:01:00 EST