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

[Dave Taht]

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 at 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 at cisco.com
>
>
>
>
>
>
>
>
>
>
>
> *From:* rmcat [mailto:rmcat-bounces at ietf.org] *On Behalf Of *Ingemar
> Johansson S
> *Sent:* Monday, March 02, 2015 8:03 AM
> *To:* rmcat WG (rmcat at ietf.org); iccrg at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150404/aaa58676/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 2526 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150404/aaa58676/attachment-0002.jpg>