Re: Odd Fast Retransmission Behavior?
| Newsgroups | gmane.linux.network.general |
|---|---|
| Message-ID | <[email protected]> |
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: > [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