Re: Odd Fast Retransmission Behavior?

[email protected] wrote:

> 1) TCP connection established
> 2) Data starts being exchanged
> 3) packet is dropped, not received by server
> 4) Client's timer expires and retransmits the packet (Frame #44)
> 5) Server ACKs this packet (Frame #45)
> 6) Client sends more data (Frames 46-48)
> 7) Server starts dup acking (Frames 49-51)
> 8) After these 3 dup acks, client does NOT retran immediately.  Rather 
> it delays and then retransmits (Frame 52)

I had the same behaviour with a 2.6.27.x server (SLES11 SP1) downloading 
data to a Windows XP client. Some piece of equipment in the middle was 
allergic to FRTO. The workaround was to set net.ipv4.tcp_frto = 0.

http://thread.gmane.org/gmane.linux.network/161172/focus=161221

 > Short question: When Linux is using CUBIC, after receiving 3 dup acks
 > should the network stack always immediately send the "missing" packet?
 >
 > I believe it should per RFCs.  However, I'm not seeing that behavior.

Not sure on that. Which RFC?

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html