mclab-cuhk / Stateful-TCP

This project presents the source code of Stateful-TCP, which has been accepted by IEEE ACCESS (Stateful-TCP - A New Approach to Accelerate TCP Slow-Start)
2 stars 1 forks source link

Can not reproduce results, still only seeing tcp slow-start #1

Open basisbit opened 3 years ago

basisbit commented 3 years ago

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 of install 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, however dmesg contains a warning stating

[x] scubic_release: loading out-of-tree module taints kernel.
[x] scubic_release: module verification failed: signature and/or required key missing - tainting kernel

However, 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 with cat /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: image

using 150ms of additional latency by the tool clumsy: image

with additional 350ms of latency using clumsy: image

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?

image

mclab-cuhk commented 3 years ago

Hi Basisbit,

Sorry for the late response and thanks for trying S-Cubic.

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?

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)