Re: [Bloat] [rmcat] Scream C++ source code available

Re: [Bloat] [rmcat] Scream C++ source code available

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 4386 bytes --]

it is always awesome to see testable source code. A core area we have not
been able to test with netperf-wrapper and other tools are the
characteristics of videoconferencing traffic. This looks to be a start! thx!

On Mon, Mar 2, 2015 at 5:46 AM, Bill Ver Steeg (versteb) <versteb@cisco.com>
wrote:

>  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
>
>
>
> [image: http://www.cisco.com/web/europe/images/email/signature/logo05.jpg]
>
> *Bill Ver Steeg*
> DISTINGUISHED ENGINEER
> versteb@cisco.com
>
>
>
>
>
>
>
>
>
>
>
> *From:* rmcat [mailto:rmcat-bounces@ietf.org] *On Behalf Of *Ingemar
> Johansson S
> *Sent:* Monday, March 02, 2015 8:03 AM
> *To:* rmcat WG (rmcat@ietf.org); iccrg@irtf.org
> *Subject:* [rmcat] SCReAM C++ source code available
>
>
>
> 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 (*S*elf-*C*locked *R*at*e* *A*daptation for *M*ultimedia) 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
>
> ingemar.s.johansson@ericsson.com
>
> www.ericsson.com
>
>
>
> “The Earth is a very small stage in a
>
>  vast cosmic arena”
> Carl Sagan “Pale Blue Dot”
> =================================
>
>
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

[-- Attachment #1.2: Type: text/html, Size: 14493 bytes --]

[-- Attachment #2: image002.jpg --]
[-- Type: image/jpeg, Size: 2526 bytes --]

Re: [Bloat] [rmcat] Scream C++ source code available

[Ingemar Johansson S]

[-- Attachment #1.1: Type: text/plain, Size: 4608 bytes --]

Hi

And thanks!, please let us and the RMCAT group know if you do “real” implementations based on the C++ code.

/Ingemar

From: Dave Taht [mailto:dave.taht@gmail.com]
Sent: den 4 april 2015 15:23
To: Bill Ver Steeg (versteb)
Cc: Ingemar Johansson S; rmcat WG (rmcat@ietf.org); iccrg@irtf.org; bloat
Subject: Re: [rmcat] Scream C++ source code available

it is always awesome to see testable source code. A core area we have not been able to test with netperf-wrapper and other tools are the characteristics of videoconferencing traffic. This looks to be a start! thx!

On Mon, Mar 2, 2015 at 5:46 AM, Bill Ver Steeg (versteb) <versteb@cisco.com<mailto:versteb@cisco.com>> wrote:
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
versteb@cisco.com<mailto:versteb@cisco.com>











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

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<tel:%2B46-73%20078%203289>
ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>
www.ericsson.com<http://www.ericsson.com>

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




--
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

[-- Attachment #1.2: Type: text/html, Size: 22028 bytes --]

[-- Attachment #2: image001.jpg --]
[-- Type: image/jpeg, Size: 2526 bytes --]