Android TCP settings tweak

[fiftydinar]

Hello,

I am curious which TCP parameter is the best?

1. cubic
2. reno
3. westwood
4. htcp
5. bbr

I read that Google's BBR algorithm is the best regarding bandwidth and latency.

I also wonder can this be enabled on Windows as it can be enabled on Linux?
Also how BBR compares to CTCP?

Thank you.

[Philip]

I would either use Cubic or BBR v2 (if available)

Most congestion control/avoidance algorithms scale the TCP window based on packet loss, and some also consider latency/RTT. BBR is also rate-based, but it uses latency.

The trick with all these congestion control algorithms is to find one that scales up the TCP send window fast, even in the presence of packet loss, yet is not negatively affected by other congestion protocols used by other nodes on the network.
Some older ones are too "nice" , like TCP-Vegas (it is too quick to throttle down speed because it does it based on latency/rtt rather than packet loss). When it is in the presence of other nodes using a more aggressive algorithm that only considers packet loss, TCP-Vegas will throttle down before everyone else, slowing your connection down.

CUBIC is the newest default in later Windows 10 builds, and Linux. it works well. It is also very popular on the Internet, probably the most popular algorithm.
CTCP is a great choice as well, but no longer available in newer Linux kernels, it used to be available as a patch.
RENO and TAHOE are just ok, but they have some drawbacks and are getting old (1986).
Westwood is a newer version of RENO, it is good, especially with WiFi connections (recovers faster from congestion).

Basically all those will divide/share available bandwidth more or less equally: Reno, CUBIC, YeAH, HighSpeed, LP, Hybla
They may vary a bit on how fast they scale back up in the presence of congestion/packet loss.


BBR algorithm is very new comparatively, but it is gaining popularity and is still being developed. It follows a new trend, it uses modeling, it is rate-based, rather than just delay/loss based.
It is good, but it largely depends on how well it interacts with all those older algorithms floating around the net, and whether its implementation in Linux is good.

Also, version 1 and 2 of BBR are quite different (v2 uses loss and ECN, v1 doesn't). You can read a bit more about BBR here:
https://www.speedguide.net/articles/...omparison-7423

The good part is BBR copes well with packet loss, much better than most other algorithms.. But version 1 causes more packet retransmissions, and doesn't play fair with CUBIC.
The only way would be to test it, I haven't really used it.

[fiftydinar]

Interesting info! I asked this because i have custom kernel on Android which allows me to control TCP algorithms. I'm not sure if it's BBRv1 or BBRv2, in changelog developer said it's just BBR. It could be BBRv2 because developer added commit from latest sources.

"But version 1 causes more packet retransmissions, and doesn't play fair with CUBIC."
- Wait, so BBR is dependent on other TCP algorithms? Or i didn't understand the sentence correctly?

I applied changes, and compared to cubic, i noticed no special difference. I could feel that WiFi is a bit more responsive per say, but it could be the placebo. Still no loss, so i will keep BBR.

[Philip]

BBR is very good modern algorithm, and it should be great for Android.

Not sure when version 2 of BBR got implemented, it has been around for about a year now.

As to it "not playing fair" with others, it refers to the fact that your device is not alone on the network, it shares limited bandwidth with many other connections. When those connections use different congestion control algorithms, they get different percentage of the available bandwidth, because some algorithms are more aggressive than others.

Regardless, I don't think it would be an issue with your Android device, I was just comparing them and maybe overthinking it.

[fiftydinar]

Now I understand, thanks! I don't mind taking a bit more bandwidth than others lol.

[Philip]

Now I understand, thanks! I don't mind taking a bit more bandwidth than others lol.

If the bandwidth is available for the taking, we are paying for it, and we can improve the speed of our connections, why not? It is not like you're disrupting others, Google has been using it for four years now.