Subject: [rmcat] CS244 ’16: Self-clocked Rate adaption for Conversational Video in LTE

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 8 Sep 2016 07:28:04 +0000

Hi

By accident I found the test report for SCReAM at the link below, published May 30
https://reproducingnetworkresearch.wordpress.com/2016/05/30/cs244-16-self-clocked-rate-adaptation-for-conversational-video-in-lte/

Some comments.
The results show that SCReAM fails when subject to competing TCP flows. This is true in some cases and especially when the bottlenecks constitute tail drop queues with large buffers that give several 100ms extra queue delay at congestion.
The work on the competing flows compensation has been quite difficult to conclude with 100% success, the problem is that any solution to this problem has to compromise between the risk of causing self-inflicted congestion and the ability to work when subject to competition from TCP flows in bufferbloated links. One specific problem I have had is that, while it is possible to devise an algorithm that does well against TCP in reasonably bufferbloated links, these algorithms can easily cause self-inflicted congestion in LTE simulation cases. I needed to strike some compromise here.
I observe that the OWD (or actually queue delay) increases up to 700ms in the experiment, I get the feeling that this bottleneck buffer is very large (or infinite), there is not a chance that SCReAM can compete against TCP under these circumstances.

Thanks for the comments in the Critique and Challenges section, some comments:
+ The max bitrate is not limited to 1Mbps, it is configurable. In fact it has been run as high as 5-6Mbps in the tests with OpenWebRTC, in this case it was the CPU demands of the video coder that limited higher throughputs.
+ Packet pacing: I don’t believe that packet pacing is limiting but need to check it up, see later in the text that the feedback interval was perhaps the limiting factor?. The updated version of the C++ code contains code in ScreamRx that better determines when and how often to send feedback, based on the received media bitrate, this should make it possible to reach higher bitrates (up to 5-10Mbps) without problems.
+ Parameters: There are a number of constants and parameters, I have tried to make the interfaces easier to use in the
updated code, in essence it should suffice to set a min and max media bitrate.
+ Readability: You are right, this is always a challenge, I did a major rehaul of the code and interfaces in July but there is definitely still work to do.

Regards
Ingemar Johansson