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) <vers...@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 > vers...@cisco.com > > > > > > > > > > > > *From:* rmcat [mailto:rmcat-boun...@ietf.org] *On Behalf Of *Ingemar > Johansson S > *Sent:* Monday, March 02, 2015 8:03 AM > *To:* rmcat WG (rm...@ietf.org); ic...@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.johans...@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
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat