Subject: [iccrg] SCReAM C++ source code available

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 2 Mar 2015 13:02:43 +0000

Hi

Please find C++ source code for the SCReAM congestion control candidate algorithm at
https://github.com/EricssonResearch/scream
This code can be useful for experiments with SCReAM. The experimental code includes a simple video and network model for initial experiments, the code should however be fairly easy to integrate into e.g. ns3 for more in-depth studies.

Please note also that work is ongoing to integrate SCReAM in OpenWebRTC, the long term intention is to make OpenWebRTC pluggable for other congestion control algorithms as well.  Go to http://www.openwebrtc.io/ for more information about the OpenWebRTC project.

Short executive summary :
SCReAM (Self-Clocked Rate Adaptation for Multimedia) is a congestion control algorithm devised mainly for Video. Congestion control for WebRTC media is currently being standardized in the IETF RMCAT WG, the scope of the working group is to define requirements for congestion control and also to standardize a few candidate solutions. SCReAM is a congestion control candidate solution for WebRTC developed at Ericsson Research and optimized for good performance in wireless access.

Regards
Ingemar
=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

"The Earth is a very small stage in a
 vast cosmic arena"
Carl Sagan "Pale Blue Dot"
=================================

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 2 Mar 2015 14:20:10 +0000

Hi

The submitted code does not send packets over a live network, it is possible to modify it for this however.

On the sender side you need to implement an RTP packet queue that allows for ScreamTx to get information about the number of queued packets, in addition you need to add the realtime stuff to handle the packet transmission when the ScreamTx::isOkToTransmit indicates that it is Ok to transmit the packets.  The flowchart on page 9 in SCReAM-description.pdf describes the call flow for the events that

1)      New video frames are generated

2)      New RTCP feedback is received

3)      A transmit timer expires
The code in scream_01.cpp also gives an idea about the call flow.

You need to implement the actual RTCP feedback , ScreamRx and ScreamTx does only provide with / use the feedback elements, you need to add the packetization and parsing.

I implemented the whole thing as Visual Studio 2010 project, but you should not let that scare you off, the code does not use any exotic types that are MS C++ specific so it should be portable to gcc with relatively little effort.

The OpenWebRTC implementation will do all the things above for you  of course, with support for H264 and VP8. It is not available yet however, but work is ongoing.

And, yes, it is surely interesting to see evaluations.

/Ingemar

From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
Sent: den 2 mars 2015 14:47
To: Ingemar Johansson S; rmcat WG ([email-masked]); [email-masked]
Subject: RE: Scream C++ source code available

Ingemar-

I read the document on the repository, and it is not clear to me if the test code actually sends packets over a live network or not. It seems to use a simulated wireless network, but I am not sure.

I am currently running some tests on how ABR video (mostly MPEG DASH) interacts with the various AQM schemes (Codel, PIE, FQ_Codel, FQ_PIE) and it would be pretty easy for me to add a few SCREAM tests to my testbed. I could make these test results available to this group, if that would be interesting.........If there is a way to have the SCREAM C++ code send data over a live network using a simple script, I could plug that in pretty easily. The MS Visual Studio dependencies do not thrill me, but I can get past that 8-).

In the preliminary ABR testing, we have seen that the ABR algorithms actually work better when run on networks that do modern AQM. As you probably know, most ABR algorithms only use loss as a congestion signal and do not use delay at all. When a link experiences bloat/delay (using large-buffer-tail-drop), the loss signal is delayed. It can be significantly delayed. This does have some impact on the ABR algorithms. The most obvious artifact is a new ABR session taking a longer amount of time to get enough data to display its first video chunk, but there also appear to be some impacts on the baseline rate adaptation algorithm. We are still quantifying these impacts.......

It would be interesting to compare how the candidate WEBRTC algorithms handles <timely loss events via AQM> vs <packet delay and subsequent loss events via legacy buffer management algorithms>.

Bvs

[http://www.cisco.com/web/europe/images/email/signature/logo05.jpg]

Bill Ver Steeg
DISTINGUISHED ENGINEER
[email-masked]<mailto:[email-masked]>

From: rmcat [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: Monday, March 02, 2015 8:03 AM
To: rmcat WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: [rmcat] SCReAM C++ source code available

Hi

Regards
Ingemar

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289