Re: Odd Fast Retransmission Behavior?

["Altan (altan@xxxxxxx)" <altan@xxxxxxx>]

Perfect.  I will look into this.

>>> Not sure on that. Which RFC?

RFC2582 and the older 2001, for example.

Thanks again!

On Mar 11, 2011, at 5:12 PM, Michael Smith wrote:

> altan@xxxxxxx 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html