From: Dave Taht <dave.taht@gmail.com>
To: "Bill Ver Steeg (versteb)" <versteb@cisco.com>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>,
"rmcat WG \(rmcat@ietf.org\)" <rmcat@ietf.org>,
"iccrg@irtf.org" <iccrg@irtf.org>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [rmcat] Scream C++ source code available
Date: Sat, 4 Apr 2015 06:23:10 -0700 [thread overview]
Message-ID: <CAA93jw6D4CkAvhcvNDzQ5K0Uq-naVQZzTrhmaBfsiuMf41=KhQ@mail.gmail.com> (raw)
In-Reply-To: <AE7F97DB5FEE054088D82E836BD15BE93195BDE8@xmb-aln-x05.cisco.com>
[-- 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 --]
next parent reply other threads:[~2015-04-04 13:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AE7F97DB5FEE054088D82E836BD15BE93195BDE8@xmb-aln-x05.cisco.com>
2015-04-04 13:23 ` Dave Taht [this message]
2015-04-10 12:03 ` Ingemar Johansson S
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw6D4CkAvhcvNDzQ5K0Uq-naVQZzTrhmaBfsiuMf41=KhQ@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=iccrg@irtf.org \
--cc=ingemar.s.johansson@ericsson.com \
--cc=rmcat@ietf.org \
--cc=versteb@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox