netdev
[Top] [All Lists]

Re: Linux TCP/IP stack (fwd)

To: rabeeh@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
Subject: Re: Linux TCP/IP stack (fwd)
From: Nivedita Singhvi <nivedita@xxxxxxxxxxx>
Date: Thu, 26 Jul 2001 09:40:18 -0700 (PDT)
Sender: owner-netdev@xxxxxxxxxxx
> 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




<Prev in Thread] Current Thread [Next in Thread>
  • Re: Linux TCP/IP stack (fwd), Nivedita Singhvi <=