litespeedtech / litespeedtech/lsquic

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

Open
#282 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
1.9k
Forks
397
Avg merge
2d 22h
Merged PRs (30d)
8

Description

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.
![network topology](https://user-images.githubusercontent.com/29472601/119824815-e23a4a00-bf28-11eb-8379-cd5215b499c3.PNG)

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source files or tests are named. Start by reproducing the reported 60 MB lsquic-versus-TCP throughput test in the described two-AP wireless topology with interference, comparing Cubic and BBR, then inspect the relevant transport and congestion-control paths; done requires identifying a reproducible cause or measurable improvement.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
networking, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.