Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Some commentary . . .
Note: Never increase the output queue in an attempt to prevent output drops. If packets stay too long in the output queue, TCP timers can expire and trigger retransmission. Retransmitted packets only congest the outgoing interface even more.
"Never" is a very strong adjective.
I believe there are instances where increasing the egress queue might be necessary. For example, to get TCP to fully utilize a path's bandwidth, the TCP receiver's RWIN needs to be able to handle the BDP (bandwidth delay product). If the network's device egress bandwidth is less than the sender's, that device will queue the sender's TCP transmission bursts. So, you'll want to insure that network device can accept the difference between the sender's transmission rate and the device's transmission rate for half the BDP.
e.g.
You have a 100 "WAN" interface with 100 ms, RTT so BDP is 10,000,000 bits.
If the sender is sending at gig, which is 10x the "WAN" bandwidth, you'll need to queue 90% of half the BDP on the WAN, which is 4,500,000 bits. If sending 1500 byte packets, you'll need to queue 375 packets. (Which if sent at 100 Mbps, will take 45 ms.)
Or, for another example, since network devices queue/count frames/packets, but BDP is in bits, smaller frames/packets will require a larger frame/packet count to meet BDP goals.
If the prior example, if packets were only 150 bytes, you would need to queue 3,750 of them.
If you correctly allow for the above, TCP timeouts, due to queuing latency, should be a non-issue.
BTW, sometimes you need to reduce a default queue depth to insure a sender's "knows" ASAP when it hits the BDP.
Congestion avoidance is based on intentional packet drops. The window size in TCP connections depends on the round trip time. Therefore, these intentional drops slow down the rate at which the source device sends packets. Congestion avoidance uses weighted random early detection.
If unwanted output drops still occur after you implement these mechanisms, you need to increase the line speed.
CA may indeed use intentional drops, but there are other techniques too. Some later TCP implementations watch for jumps in latency. Some traffic shaping appliances might shape TCP ACKs and/or spoof the TCP receiver's advertised window size. In theory, ECN can be used to indicate congestion w/o the need to drop a packet.
WRED is actually rather complex to get "right". Unless you're a QoS expert, I advise staying away from it. FQ tails drops, I believe, often works better than WRED. In theory, Cisco's FRED should work better than WRED, but it too can still be difficult to get "right".
With really effective bandwidth management for rate adaptive traffic, you shouldn't get unwanted output drops and shouldn't need to increase bandwidth unless you need to improve throughput rate. With non-rate adaptive traffic, "right sizing" bandwidth is really a requirement.
