search

tobiasfl / tobias-master-thesis-webrtc

0 stars 0 forks source link

Implementing ROSIEEE and FSE-NG #8

Closed tobiasfl closed 8 months ago

tobiasfl commented 3 years ago

Hi, Joakim's code was very helpful and I can register callbacks for setting the cwnd of the SCTP connections now. Next I will implement ROSIEEE, but I am a bit confused about on thing. Here is a picture of the algorithm from the paper so you don't have to find it: image I am able to get both the RTT and rate change values from the update call which will be made in send_side_bandwidth_estimation.cc but I don't think there is a way for me to get the number "i" of the last received RTCP packet. Would it work if "i" in my case is a counter that is incremented for each update call?

tobiasfl commented 2 years ago

No. I calculated that the BDP is 25 packets, but the queue only has 12. With a full BDP of queuing (i.e., 25 packets in this case), the RTT would double (i.e., up to approx 100ms). This goes even above 100, with a much smaller queue. How did you measure the RTT?

I believe I had already changed to a queue of 15 packets when I made that plot, but I suppose the point still stands. Both the sctp cwnd and rtt measurements are extracted from the chromium log, so they are the values used inside the actual sctp congestion controller code.

Are you using virtual machines? Maybe that's the problem, some timing issue there?

I am using two different computers with an ethernet cable between them.

I suggest to run a very simple TCP transfer to see if the tc setting is right! No browser, no SCTP, nothing. TCP, and set it to Reno.

iperf says it is 3.06 Mbits/sec on the client side and 2.87 Mbits/sec on the server side, which one is considered most accurate normally? This is most likely running cubic by default though, I'll try to see if I can find a way to test with Reno. I am not sure how I can get an exact plot/measurement of the cwnd though, tcpdump would only give throughput right?

mwelzl commented 2 years ago

I believe I had already changed to a queue of 15 packets when I made that plot, but I suppose the point still stands.

Yes.

Both the sctp cwnd and rtt measurements are extracted from the chromium log, so they are the values used inside the actual sctp congestion controller code.

Aha! You could do a simple ping on the side to see if this also grows so high. Also, when doing a TCP test with iperf, you could at least get the RTT from a pcap on the client and a pcap on the server side, with this tool: http://caia.swin.edu.au/tools/spp/ cwnd is not visible with tcpdump, that's right. There's a tool that people use to get it from the kernel. Ages ago it was called Web10G, but now there's something newer that everyone knows and uses - but I don't remember its name :(

tobiasfl commented 2 years ago

You could do a simple ping on the side to see if this also grows so high.

Tried this now, the sctp rtt plot looked similar to the one above, while the pings stay around the 50's sometimes barely exceeding 60ms. I'll have a look at getting the TCP cwnd now.

mwelzl commented 2 years ago

Aha. That's expected: tc appears to work as it should, and some extra delays are caused inside the browser. Most likely, the cwnd plot from TCP will also look normal. Then, at least, you have identified the culprit!

tobiasfl commented 2 years ago

Nice! Should I still find a way to plot cwnd just to be sure? Also what to do about this? Test results between SCTP vs. GCC and etc. I suppose will make sense since they both run in the browser right? But if TCP always kills any flows running in the browser because of the extra delay it is a bit difficult to test the efficacy of any mechanism I implement.. I happened to try with a queue length of 24 earlier and then SCTP was suddenly able to reach 3Mbit/sec: image But it still struggles to compete with TCP though so I guess simply increasing the queue length is not a solution?

safiqul commented 2 years ago

Aha. That's expected: tc appears to work as it should, and some extra delays are caused inside the browser. Most likely, the cwnd plot from TCP will also look normal. Then, at least, you have identified the culprit!

I think Tobias did run simple iperf tests and pings to check whether tc settings are correctly applied. It is the browser we know for sure! I also agree that the cwnd plot will look normal here.

safiqul commented 2 years ago

But if TCP always kills any flows running in the browser because of the extra delay it is a bit difficult to test the efficacy of any mechanism I implement..

I don't if people checked the performance of both SCTP and GCC flows against background traffic. But, for sure, I know that a GCC flow should be able to compete with a TCP flow - the results for the RMCAT group proved that.

Increasing the queue length is not a solution to make it work but it is worth checking with varying queue lengths.

tobiasfl commented 2 years ago

GCC flow should be able to compete with a TCP flow - the results for the RMCAT group proved that.

Do you happen to have the paper, maybe I can look at their test cases? Also did they do it with GCC in the browser or in a simulator? I have previously seen GCC aggressively compete against TCP when bandwidth was 10mbit and queue length at 34, but I'm struggling to make it work with 3mbit and smaller queue lengths.

safiqul commented 2 years ago

I'm sure that you've read this paper:

https://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf

also look for the ietf presentations related to GCC

safiqul commented 2 years ago

Is this at all relevant? https://stackoverflow.com/a/56330726 I did apply the optimization tips for message size and low/max threshold to my application, but it did not change anything.

I think NOT because they were able to reach 100 Mbps or more... but in your case, your SCTP flow can't even utilise bw less than 10....

safiqul commented 2 years ago

Performance analysis of webrtc data channel

https://ieeexplore.ieee.org/document/7884873