3 ms·

Can I get an explanation why bufferbloat is? As in, why is it slowing things down? I got it's to do with big caches on devices? Or not? The article is extremely

by rplnt 8y ago

Can I get an explanation why bufferbloat is? As in, why is it slowing things down? I got it's to do with big caches on devices? Or not? The article is extremely long without ever getting into it (I didn't click the article I was told not to click).

learc83 8y ago
The TCP congestion control algorithm depends on dropped packets to calculate bandwidth. TCP will send more and more packets per second until they start dropping, then it will back off. If there is a huge buffer, it will take a while for packets to start dropping, so the congestion control algorithm won't function optimally--it won't respond fast enough and lower the rate it sends packets until the buffer is full and packets start dropping. Once the buffer is full, packets have to wait in line in the buffer until they can be sent along so they take longer to get to their destination. Eventually the buffer empties, but then the TCP congestion control algorithm starts increasing the rate it's sending packets and starts the problem over again. You end up with a very variable latency--depending on where in the cycle you are.
- tschwimmer 8y ago
  Really good summary.
- Animats 8y ago
  Actually, one TCP connection all by itself will do fine. It's multiple connections that will get you. In particular, doing an upload and a download at the same time will show terrible performance if there's a big FIFO buffer in the upload direction. The ACKs for the download, a small number of bytes, get stuck behind the bulk upload traffic. This runs the measured round trip time way up and causes the download TCP stream to slow. This is why uploads interfere with downloads, even though they shouldn't.
  - learc83 8y ago
    >Actually, one TCP connection all by itself will do fine. That depends on your metric. It isn't necessarily true if you're targeting stable latency for whatever reason.

by rplnt 8y ago

learc83 8y ago

The TCP congestion control algorithm depends on dropped packets to calculate bandwidth. TCP will send more and more packets per second until they start dropping, then it will back off. If there is a huge buffer, it will take a while for packets to start dropping, so the congestion control algorithm won't function optimally--it won't respond fast enough and lower the rate it sends packets until the buffer is full and packets start dropping. Once the buffer is full, packets have to wait in line in the buffer until they can be sent along so they take longer to get to their destination. Eventually the buffer empties, but then the TCP congestion control algorithm starts increasing the rate it's sending packets and starts the problem over again. You end up with a very variable latency--depending on where in the cycle you are.

tschwimmer 8y ago
Really good summary.
Animats 8y ago
Actually, one TCP connection all by itself will do fine. It's multiple connections that will get you. In particular, doing an upload and a download at the same time will show terrible performance if there's a big FIFO buffer in the upload direction. The ACKs for the download, a small number of bytes, get stuck behind the bulk upload traffic. This runs the measured round trip time way up and causes the download TCP stream to slow. This is why uploads interfere with downloads, even though they shouldn't.
- learc83 8y ago
  >Actually, one TCP connection all by itself will do fine. That depends on your metric. It isn't necessarily true if you're targeting stable latency for whatever reason.