Throughput lower than TCP at MANET(mobile Ad-hoc NETwork)

[Jankin-Xu]

Hello, I've been doing some throughput performance tests comparing lsquic with the TCP. In the ethernet, lsquic can get higher throughput than TCP in almost every Packct Loss Ratio case. However, when I test it in wireless environment, it seems lsquic has no performance advantage adding RFI(radio frequency interference).

Here is my network topology

1. pc1(Personal Computer) and pc2 connect to AP1(access point / WiFi router) by wireless, and use them to do throughput test comparing lsquic with the TCP.
2. pc3 and pc4 connect to AP2(the wifi channel is the same as AP1),use iperf to do tcp/udp throughput test for adding RFI.

In the experiment above, pc1 use lsquic/tcp for requesting a file of 60 MB from pc2, and calculate the throughput by time it takes. In this case, it shows that the throughput of lsquic(Cubic/BBR) is lower than TCP most of the time.

Have you encountered similar phenomena in wireless weak environment? Could you give me some advice, because I cann't find any effective ways to improve lsquic throughput in this case now.

[litespeedtech]

How big is the difference between lsquic and TCP? Detail numbers? As I know lsquic is not very good handling high packet loss. It is not tuned for that. To figured out what is going on, need to measure the RTT and packet loss ratio for the wireless environment.

[Jankin-Xu]

1. Without pc3 and pc4's RFI( RTT around 10ms, packet loss within 0.1%) , throughput: TCP 180Mbps and lsquic 160Mbps(due to wireless net card performance),
2. Add pc3 and pc4 RFI, RTT increase to 20ms, packet loss increase to around 0.3%(some time increase to 0.5% dute to wireless unstable), TCP in this case run 120Mbps but lsquic decreases to around 60Mbps, the difference is so big, In this case, I do udp/tcp test by iperf, it can run around 120Mbps within 0.1% packet loss.

By the way, the Packct Loss Ratio within 10%, my test show lsquic can get higher throughput than TCP in the ethernet. Is there any mechanisms impact this case in lsquic congestion control algorithms? (wireless unstable environment led to packct loss randomly , or maybe other mechanisms I donn't know ? )

I think lsquic doesn't take full advantage of effective bandwidth like tcp in this case. How can I get the relevant debugging information about the lsquic congestion control?

[litespeedtech]

Do you know which congestion control is used? BBR or Cubic? We knew our BBR implementation may not get correct bandwidth estimation for fast network. -l option can be used to change log level for different module. for example, -l bbr=debug will turn on debug logging for BBR. for detail, please read lsquic_logger.c .

[Jankin-Xu]

OK, thanks.
In my case, the difference is not that big with BBR and Cubic. I set option " -o cc_algo=1" or " -o cc_algo=2" to use Cubic/BBR. By the way, have you tested lsquic in wireless environment before? I want to know adbout the performance of lsquic in wireless environment.

[litespeedtech]

No, we have not specifically measured throughput through wireless connection.

[Kiddinglife]

Hey @Jankin-Xu @litespeedtech this research article might help to explain the low throughputs in wireless environment. https://upcommons.upc.edu/bitstream/handle/2117/172208/main.pdf

looks like delay ack is playing the key to achieve the higher throughputs when packet loss is low but lower throughputs when packet loss higher. I think it makes sense if the Root reason is wifi Collisions among ack and data packets.

[Jankin-Xu]

Get it，thanks for your reply.