←back to thread

360 points pjf | 4 comments | | HN request time: 0.806s | source
Show context
notacoward ◴[] No.14299101[source]
It's almost irresponsible to write an article on this topic in 2017 without explicitly mentioning bufferbloat or network-scheduling algorithms like CoDel designed to address it. If you really want to understand this article, read up on those first.

https://en.wikipedia.org/wiki/CoDel

replies(5): >>14299422 #>>14299475 #>>14299613 #>>14301482 #>>14304236 #
throwasehasdwi ◴[] No.14299422[source]
CoDel is different from the packet scheduling algorithm even though both fight bufferbloat in different ways. CoDel is a congestion control algorithm for controlling what happens when outgoing buffers start overflowing. This is on a lower level than TCP and happens to any type of packet. The scheduling algorithm, like VEGAS or BBR, controls the transmit rate of only the TCP protocol.

When packets are being sent over the wires, the TCP scheduling algorithm (usually CUBIC, VEGAS, RENO, or now BBR) will send out packets until the parameters they monitor indicate the downstream device is about to overload. Then they will back off slightly to prevent packets from being lost. These TCP transmit strategies tend to either monitor packet loss rate or round trip time, sometimes both. What they do with these two parameters determines the biggest differences between the packet sending algorithms.

CODEL comes into affect when the scheduling algorithm decides it can't send out packets quickly enough without losing them, and they build up on local buffers. This can happen with TCP but also other internet protocols.

Something most people don't know is that without a scheduling algorithm like BBR,VEGAS, or RENO, you can send out packets at interface speed. In simpler protocols like UDP you need to do your own packet scheduling. Otherwise your machine will send out packets at interface speed until they are mostly dropped by the first slower link. This is why TCP has scheduling algorithms, they're all an attempt to monitoring the end to end link speed from A to B you can achieve without losing data.

Edit: BBR is a new TCP scheduling algorithm to fight buffer-bloat at the TCP level. Since the majority of internet traffic is TCP, wide adoption would cause a big improvement. TCP scheduling only affects outgoing packets, so its important to get this into Windows and Linux so we can get the full benefit of having buffer-bloat reduction on both ends. I'm looking at MS here because they're the last major OS running an aggressive and buffer-bloat causing TCP algorithm.

replies(4): >>14299445 #>>14299669 #>>14303111 #>>14310578 #
1. Klathmon ◴[] No.14299669[source]
Do you have any information on Window's TCP algorithms and why they are so bad, or what kinds of problems they cause?
replies(2): >>14299764 #>>14303142 #
2. throwasehasdwi ◴[] No.14299764[source]
By default, Windows machines use the algorithm NewReno. Older algorithms like NewReno are known for causing horrible buffer-bloat in comparison to algorithms like VEGAS which is used in Linux. The reason is pretty simple. The two main metrics used for determining when to send a packet in TCP are round trip delay and packet loss.

Reno/NewReno slow their send rate mainly when they detect lost packets, whereas VEGAS and similar mainly detect round trip delay but also respond to loss. The problem with primarily loss-based strategies is that most routers won't drop packets until their buffers are full. In modern times these buffers can be very large (many seconds). TCP Reno will keep sending packets until downstream routers have full buffers and drop packets, which could be when they're already holding seconds worth of data. This is buffer-bloat. Any packets that makes it to these routers will spend seconds waiting to be put on the wire.

VEGAS on the other hand will try to maintain a constant round trip delay. It uses TCP's ACK packets to gauge how long it takes packets to go back and forth and reduces send rate when this starts to rise. This keeps router buffers empty, delay low, and packet loss near zero. BBR is a further enhancement of the VEGAS delay sensing strategy.

As mentioned in this chain, CoDel is one strategy for "fixing' loss based aggressive protocols like TCP Reno. It detects "flows" (IP/port pair combinations) that are causing the local outbound buffers to overflow and starts selectively dropping packets on them. If all internet protocols were delay based like TCP VEGAS CoDel would not be needed to keep traffic flows "fair". Without using something like CoDel on your routers to punish aggressive strategies, scheduling algorithms like NewReno will cause your routers outgoing buffers to always be full and out-compete friendlier traffic like VEGAS that cuts itself back when buffers fill.

replies(1): >>14299783 #
3. metafnord ◴[] No.14299783[source]
little side node here: the windows 10 creator's update introduced experimental support for CUBIC https://www.ietf.org/proceedings/98/slides/slides-98-tcpm-tc... which is currently the default CC algorithm used in linux. However, the slides state that in the absence of AQM qdelay gets worse when CUBIC is used
4. kev009 ◴[] No.14303142[source]
Note that in most cases TCP congestion control only really matters from the sender side. Windows has a fairly nice algorithm called Compound TCP if you are sending from Windows https://en.wikipedia.org/wiki/Compound_TCP