7 ms·
Queuing tends not to be a great traffic shaping strategy. The problem is that the sender will almost certainly not react to the extra queuing delay in any way (
by jsnell 10y ago
Queuing tends not to be a great traffic shaping strategy. The problem is that the sender will almost certainly not react to the extra queuing delay in any way (nobody runs RTT-sensitive congestion control in practice). And if the sender doesn't react to the queuing, it'll fill up the buffer and the same amount of packets will be dropped anyway. So you got increased RTTs and no reduction in packet loss.
There is a better way of doing shaping for TCP traffic, by making the sender reduce the rate of transmission by other means than dropping packets. For example via manipulating the receive window. (And other, more sophisticated variations on that). But these methods aren't applicable to UDP in general, at best to some small subset of UDP-based protocols.
- AstralStorm 10y agoEven TCP Reno is sensitive to RTT and if it's ubiquitous. Likewise common Linux BIC and CuBIC. Plenty of VoIP and video streaming protocols also handle RTT hikes.