From 54632fc2be6f4c8468871d1b508122df08f630eb Mon Sep 17 00:00:00 2001 From: "@RubenKelevra" Date: Tue, 31 Mar 2020 23:54:02 +0200 Subject: [PATCH] tcp congestion control algorithm - cubic vs Westwood --- .../2018.11-compression.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/design/history/exploration-reports/2018.11-compression.md b/design/history/exploration-reports/2018.11-compression.md index 97df2a1a..d11f885b 100644 --- a/design/history/exploration-reports/2018.11-compression.md +++ b/design/history/exploration-reports/2018.11-compression.md @@ -155,3 +155,27 @@ Not necessarily. WRT packet loss, a large issue there is that go-ipfs currently sends out *way* too many packets (we need to buffer better). WRT compression, I'd be surprised if intermediate nodes were all that compressible. They tend to *mostly* be composed of hashes. + +--- +#### (2020-03-31T20:31:00Z) RubenKelevra: +> * Depending on the congestion control algorithm, early requests are much slower than subsequent requests. TCP (and TFRC when using UDP) use a loss based congestion control algorithm that ramps up, increasing the send rate until it sees loss. Because we connect to multiple peers we hit this in every connection and hit it more in the initial stages of a connection, unless we're using an alternative congestion control algorithm I don't know about. +> * Mobile packet loss plays havoc with these algorithms and mobile infrastructure tries to compensate by keeping a buffer in the network layer. In the long run this helps but it tends to make the initial connection speed fluctuate with spikes up and down and sending larger amounts of data before this normalizes tends to make it worse. + +The default congestion control algorithm used by TCP on linux is cubic, which is designed for extremly large throughput in wired networks which has low latency. + +It's not made for lossy connections like wireless networks and it also tend to buffer extensively (leading to bufferbloat). + +You might want to switch to Westwood which recovers much quicker from sudden drops in wireless networks while maintaining an "ok" fairness to cubic streams. + +> For example, TCP CUBIC [11] aggressively probes for the available bandwidth leading to a high average buffer utilization, whereas TCP Westwood+ [12] clears the buffers when congestion episodes occur leading to, on average, a reduced buffer occupancy. + +And + +> The more aggressive congestion control used by CUBIC roughly doubles the Web response time as compared to Westwood+. + +And + +> All congestion control algorithms achieve similar throughput, whereas CUBIC and BIC are observed to exhibit larger RTTs and a larger number of retransmissions. + + +Source: https://c3lab.poliba.it/images/3/32/BufbloatLTE2013.pdf