Open basisbit opened 3 years ago
Hi Basisbit,
Sorry for the late response and thanks for trying S-Cubic.
You have a good point here. IMO, this one is similar to HTTPS connection setup, which we encountered before and fixed. Basically we will check the inflight (MIN_INFLIGHT_TO_EXIT_STARTUP_PHASE ) to avoid this issue.
A quick way to figure out the issue is via debugging the message. You may want to try to turn on this parameter STATEFUL_DEBUG_PRINT and run the experiment again. Then you can see the information from the kernel and locate the message contains The 1st ACK:. Normally if S-Cubic works correctly, the inflight will be larger than 10 (10 is the default Cubic's initial CWnd). In addition, please also double-check the message contains Stateful-TCP/Cubic: and Release:peer IPs, they will be printed out when an S-Cubic flow begins and ends.
As you mentioned, the BDP of your connection should be very large, say 124ms * 100Mbps = ~ 1000MSS, if S-Cubic takes effect successfully, the improvement can be quite significant (~7RTT=~900ms).
Feel free to let me know anything you need, I will check more frequently or you can just email me when you have any updates (lingfengguo@tencent.com)
After reading the very interesting paper on
Stateful-TCP—A New Approach to Accelerate TCP Slow-Start
, I spent some time to set up a sample testing environment to see how differently s-cubic would behave.For this test, I set up a HTTP based video streaming over a rented virtual server in Canada, while streaming the video source from Europe and also "watching" the video result from there. That results in roughly 124ms of ping response time. I compiled and installed the kernel module as suggested (only had to use
insmod
instead ofinstall
on this Ubuntu 20.04 server to be able to install and then later load the kernel module.lsmod | grep scubic_release
shows that the module was loaded successfully, howeverdmesg
contains a warning statingHowever, the server doesn't have secure boot enabled, so apparently that warning is ignored. Setting
sysctl net.ipv4.tcp_congestion_control=scubic
works and shows correctly when checking withcat /proc/sys/net/ipv4/tcp_congestion_control
.The bandwidth graphs however look like it is still using cubic or at least still doing tcp slow-start:
using 150ms of additional latency by the tool clumsy:
with additional 350ms of latency using clumsy:
Linux kernel is
5.4.0-66-generic
on Ubuntu 20.04. The above graphs are from downloading 6-seconds-video-chunks using a new TCP connection every time (tcp keep-alive disabled on purpose). Server and client both have Gigabit internet down-/uplink.Do you maybe have any suggestions what I might be missing or have configured incorrectly? Interesting note: before downloading the video chunk file over https, it first requests a ~400B small playlist file - could that maybe cause the tcp cache to have way too low numbers?