3 ms·
Great detective work. Before people go off reducing tcp_rmem too low, I thought I'd explain its actual purpose. A TCP sender will only send data of the receiv
by paulsutter 11y ago
Great detective work.
Before people go off reducing tcp_rmem too low, I thought I'd explain its actual purpose.
A TCP sender will only send data of the receiver has buffer space available. With 100msec of latency, at 1Gbit/sec there can be 12MBytes of data "on the wire". If a retransmit is necessary, you can multiply that by a number of round trips (say 2 or 3?) to get the needed amount of receive buffer to keep the sender sending. Otherwise per-connection throughput is reduced linearly with the tcp_rmem size.
I mention this because objects in a CDN are usually pretty small, and lower values of tcp_rmem may be ok for them.
And really I mention this hoping it motivates someone to fix the bug.
- bboreham 11y ago> if the receiver has buffer space available nitpick: if the sender believes the entire path between sender and receiver has buffer space available. I.e. it will send up to the minimum of the receive window and the congestion window. Retransmits cause the cwnd to be dramatically reduced; in my experience huge buffers really only work under perfect network conditions.
- planckscnst 11y agoI had always associated the two together. There is one "window" slot in a TCP packet. How does the sender know the receiver's receive window separately from the congestion window?
- bboreham 11y agoThe sender maintains cwnd as a completely separate parameter that does not go in any packets. It doesn't "know" anything; the value of this parameter is arrived at by some set of heuristics. See for instance https://en.wikipedia.org/wiki/TCP_congestion-avoidance_algorithm https://en.wikipedia.org/wiki/TCP_congestion-avoidance_algor...