What are the other congestion control algorithms specially designed for lossy wireless networks like LTE and WiMax?

Question

I am trying different congestion control algorithms for getting maximum throughput and minimum delay across my setup for TCP flow. Please suggest other available algorithms apart from

Veno, Westwood, Reno and Cubic

whose implementation (or kernel modules) are freely available on the Internet. And also suggest if there is some other way of obtaining higher throughput in TCP runs between Linux (Fedora) and Windows 7's TCP protocol stack at different ends.

Answer 1

BBR :).

If the packet loss rate is below 15% then BBR is able to fully utilize the path (reaching link_bandwidth*(1 - loss_rate)). This 15% threshold is a design parameter, rather than a fundamental limit

I'm struggling to explain the exact significance of this. Here's Eric Dumazet:

Compared to Cubic, there is 2 to 4 orders of magnitude difference on lossy environments.

Example of 100ms rtt, and 1% packet loss. Cubic performs very badly there.

$ netperf -H 10.246.7.152 -l 30 -- -K cubic
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    40.00       3.27   

$ netperf -H 10.246.7.152 -l 30 -- -K bbr  
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    30.25    9150.01

Third-party testing revealed / elicited an explanation that the current code expects a full buffer (BDP) at the bottleneck, if there is any competition. This is a known target for further improvement. If the condition is not met, it drives up the loss rate. Then traditional TCP's will basically starve.

If there is more buffer than 1 BDP, BBR flows will co-operate to avoid filling excess buffer, hence capping queuing delay as you requested. Traditional TCP's tend to fill the whole buffer. When both are competing, BBR cannot magically fix the behaviour of the traditional TCP flows, however I don't think this hurts BBR in any other way.

If the condition mentioned above is not met, application latency will suffer (having to retransmit lost packets).

https://groups.google.com/forum/#!forum/bbr-dev

https://www.google.co.uk/search?q=tcp-bbr

[PATCH v4 net-next 00/16] tcp: BBR congestion control algorithm

Answer 2

Relentless TCP would be the most relentless TCP you could get.