General list for discussing Bufferbloat
 help / color / mirror / Atom feed
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 --]

       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