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
