> Does anyone know how to set tcp fast retransmissions? All of > the docs I've been reading reference the tcp congestion algos > for the sender, but we are having a problem with receiving.
With SACK? Because TCP without SACK/DACK etc. is often a pain, because it uses just a high-water-mark (assumes the loss of all *bytes* after the last acknowledged byte). SACK/DACK make a very, very big difference on lossy paths. Also various congestion control algorithms make also a very big difference, as they are optimized for different cases; since the exact cause of the loss is not known/knowable, each different algorithm embodies different assumptions. There is a survey here: http://cs.gmu.edu/~huangyih/756/tcp_survey.pdf On a lossy but not congested network consider Westwood+. > [ ... ] The sender appears to be waiting for that 4th dup to > initiate a fast retrans. When it doesn't receive it, it > waits, causing big delays. The above said, often the overall problem is not the details of when congestion is detected and how it is reacted to, it is that the RTO delay at 200ms is way too big. Consider for example this paper: http://www.cs.cmu.edu/~dga/papers/incast-sigcomm2009.pdf > The following url has a decent description: > http://stackoverflow.com/questions/534957/how-does-tcp-deal-with-timeouts-with-cwnd That URL seems to me mostly rather misguided. BTW also consider the influence of MTU, 'tcp_reordering', 'txqueuelen', TSO and inter-frame delays, etc. _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
