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
-
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:01 EST