Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc

[Ingemar Johansson S <[e-mail]>]

Hi Dave

I am  not sure if you refer to the Google Congestion Control algorithm (GCC) or the self-clocked alternative (SCReAM). 
GCC is implemented in running code (I guess?) not sure though if the latest addition in (draft-alvestrand-rmcat-congestion-02) are implemented, I leave to others to comment on that.

As regards to SCReAM : No, there is no (not yet) WebRTC implementation available, I hope there will be one at least based on the same philosophy available. It depends partly on the level of attention that draft gets. The example code is in any case quite complete and it should be possible for those interested to implement the framework in NS2, NS3 or mininet (and also implement it as running code in the browsers too!). If you examine the code you will also notice that it resembles TCP quite a lot,  the equations to compute the congestion window are quite simple so I don't expect things to blow up in a real implementation. 
There are some details missing around loss event detection and congestion window validation and I plan to add it in a later version after the summer (it is already part of our proprietary code). So the bottom line is that with a little luck you should be able to run WebRTC with SCReAM as congestion control in the future but we are not there yet.

Regards
/Ingemar



> -----Original Message-----
> From: Dave Taht [mailto:[e-mail]]
> Sent: den 26 juni 2014 19:06
> To: Zaheduzzaman Sarker
> Cc: Luca De Cicco; Ingemar Johansson S; [e-mail]; rmcat WG
> ([e-mail])
> Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc
> 
> On Thu, Jun 26, 2014 at 5:10 AM, Zaheduzzaman Sarker
> <[e-mail]> wrote:
> > Hi Luca,
> >
> > The simulation code is implemented in our proprietary simulator (I
> > should thank my MS thesis workers who contributed a lot). Thus cant
> > really share the code but what I can share is some simulation results.
> 
> I have decided that I will no longer consider experimental results that cannot
> easily be reproduced independently, and will ignore future articles, internet
> drafts, and proposals that do not come with sufficient source code to
> reproduce independently.
> 
> Nearly every published experiment that actually supplied sufficient
> information, raw data and code to reproduce it - that I've had the chance to
> examine closely and/or reproduce in more varied circumstances - has been
> flawed, and I have no reason whatsoever to believe that code I cannot see
> and run is not flawed in some respect, either.
> 
> If I apply this criterion as a stage-1 filter, my workload drops enormously.
> 
> Both chrome and firefox have mostly working webrtc implementations now,
> and whatever future algorithms proposed should be able to be easily hacked
> into those and tried in real life.
> 
> open source ns2, ns3, and mininet simulators exist as well as a basis for
> future work.
> 
> My policy is obviously not the ietf's nor the position of the chairs of this wg,
> but it is in the spirit of "rough consensus and running code".
> 
> 
> > Note that in our implementation we followed latest update for varying
> > threshold from the GCC draft
> >
> > If you want GCC related logs particularly for LTE simulations I cant
> > not provide that.We simulate lots of users and dont log all the GCC
> > related variables.
> >
> > However, I have attached simulation logs from two test cases- 1. a
> > staircase bandwidth test , that I found interesting in one of the
> > papers.
> > 2. and test case 5.1 from
> > http://tools.ietf.org/html/draft-sarker-rmcat-eval-test-01.
> >
> > I hope those plots will give you an idea about the implementation we
> > have and how it is behaving.
> >
> > I would suggest you run tests from
> > http://tools.ietf.org/html/draft-sarker-rmcat-eval-test-01 as well and
> > then we can compare the results.
> >
> > BR
> >
> > Zahed
> >
> >
> >
> > On 2014-06-25 17:32, Luca De Cicco wrote:
> >>
> >> Dear Zahed,
> >>
> >> can you share some information about the GCC simulation code?
> >>
> >> thanks,
> >> Luca
> >>
> >>
> >> On Wed, Jun 25, 2014 at 2:46 PM, Ingemar Johansson S
> >> <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>     Hi____
> >>
> >>     __ __
> >>
> >>     Thanks for the interest in this work. ____
> >>
> >>     __ __
> >>
> >>     Crosspost to RMCAT as well, hope that is Ok____
> >>
> >>     Answers/comments inline____
> >>
> >>     __ __
> >>
> >>     /Ingemar____
> >>
> >>     __ __
> >>
> >>     *From:*Luca De Cicco [mailto:[e-mail]
> >>     <mailto:[e-mail]>]
> >>     *Sent:* den 25 juni 2014 13:23
> >>     *To:* Ingemar Johansson S
> >>     *Cc:* Dave Taht; [e-mail] <mailto:[e-mail]>
> >>     *Subject:* Re: [iccrg] draft-johansson-rmcat-scream-cc____
> >>
> >>     __ __
> >>
> >>     Dear Ingemar,____
> >>
> >>     __ __
> >>
> >>     I have some questions. ____
> >>
> >>     __ __
> >>
> >>
> >>     1) In the architecture figure (Figure 2) you show the case of two
> >>     videos produced by the ____
> >>
> >>
> >>     same source and going to the same destination (both videos are
> >>     encoded and fed to the same UDP socket),____
> >>
> >>
> >>     am I right? In the case SCReAM is used in a WebRTC context (in a
> >>     browser), what use case ____
> >>
> >>     are you imagining?____
> >>
> >>
> >>     [IJ] This was just to highlight how two sources are handled, I am
> >>     fully aware that it is probably not the most common use case, on the
> >>     other hand I don’t know how WebRTC will be used in the future. If
> >>     there are two destinations then one will need to congestion control
> >>     contexts (one for each UDP socket). The bandwidth distribution may
> >>     then be based on rate shaping but another, possibly more useful,
> >>     option is to target the congestion window functions directly, for
> >>     instance if the congetsion window for one flow is knocked down just
> >>     a little then the other flow will grab the free capacity
> >>     automatically. Another option is to adjust the gain factors for the
> >>     CWND calculations.____
> >>
> >>     __ __
> >>
> >>
> >>     2) How did you implement GCC algorithm? Do you have a paper where I
> >>     can see the dynamics of GCC (for instance____
> >>
> >>
> >>     the rate computed by the receiver side controller, the estimated one
> >>     way queuing delay variation "m")?____
> >>
> >>
> >>     [IJ] The GCC algorithm was implemented into our simulation platform
> >>     by Zahed, it is based in the availabe code and the drafts. We have
> >>     logging possibilities in our simulator but I don’t know of any paper
> >>     around this.____
> >>
> >>     __ __
> >>
> >>
> >>     3) You show average bitrate in the tables. There's an odd situation
> >>     where GCC gets a 50% packet loss ratio in the case of____
> >>
> >>
> >>     16 users/cell but with an average rate of 61 kbps. Can you elaborate
> >>     on this?____
> >>
> >>
> >>     [IJ] Could be an effect of a much too high load in combination with
> >>     a high mobility, could be an effect of large amount of packet losses
> >>     due to network queue overflow. I will BTW update the evaluation
> >>     results for GCC soon, it seems like it was tuned a but too
> >>     sensitive, with the new setting one get higher bitrates, but
> >>     unfortunately also the tail latency will increase more quickly with
> >>     increased load. ____
> >>
> >>     __ __
> >>
> >>     Cheers,____
> >>
> >>     Luca____
> >>
> >>     __ __
> >>
> >>
> >>     On Wed, Jun 18, 2014 at 11:37 AM, Ingemar Johansson S
> >>     <[e-mail]
> >>     <mailto:[e-mail]>> wrote:____
> >>
> >>
> >>     Hi
> >>
> >>     Besides the example code there is no ready to compile code available
> >>     (at least nothing that I know of). But on the other hand the
> >>     solution has similarities to TFWC (TCP Friendly Window-based
> >>     Congestion control) that was devised by Soo-Hyun Choi
> >>     (http://tfwc.hackerslab.eu/ ), perhaps that can be used as a basis ?
> >>
> >>     /Ingemar____
> >>
> >>
> >>
> >>      > -----Original Message-----
> >>      > From: Dave Taht [mailto:[e-mail]
> >>     <mailto:[e-mail]>]
> >>      > Sent: den 17 juni 2014 20:00
> >>      > To: Ingemar Johansson S
> >>      > Cc: [e-mail] <mailto:[e-mail]>
> >>      > Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc
> >>      >
> >>      > My usual request: Is there running code somewhere?
> >>      >
> >>      > On Tue, Jun 17, 2014 at 10:35 AM, Ingemar Johansson S
> >>      > <[e-mail]
> >>     <mailto:[e-mail]>> wrote:
> >>      > > Hi
> >>      > >
> >>      > >
> >>      > >
> >>      > > This draft can be of interest for those of you interested in
> >>      > > congestion control for realtime media.
> >>      > >
> >>      > >
> >>     http://www.ietf.org/internet-drafts/draft-johansson-rmcat-scream-cc-
> 00
> >>      > > .txt
> >>      > >
> >>      > >
> >>      > >
> >>      > > Abstract : “This memo describes a rate adaptation framework for
> >>      > > conversational
> >>      > >
> >>      > >    video services.  The solution conforms to the packet
> >>     conservation
> >>      > >
> >>      > >    principle and uses a hybrid loss and delay based congestion
> >>     control
> >>      > >
> >>      > >    algorithm.  The framework is evaluated over both simulated
> >>      > > bottleneck
> >>      > >
> >>      > >    scenarios as well as in a LTE (Long Term Evolution) system
> >>      > > simulator
> >>      > >
> >>      > >    and is shown to achieve both low latency and high video
> >>     throughput
> >>      > > in
> >>      > >
> >>      > >    these scenarios”
> >>      > >
> >>      > >
> >>      > >
> >>      > > /Ingemar
> >>      > >
> >>      > >
> >>      > >
> >>      > >
> >>      > >
> >>      > > =================================
> >>      > >
> >>      > > Ingemar Johansson  M.Sc.
> >>      > >
> >>      > > Senior Researcher
> >>      > >
> >>      > >
> >>      > >
> >>      > > Ericsson AB
> >>      > >
> >>      > > Wireless Access Networks
> >>      > >
> >>      > > Labratoriegränd 11
> >>      > >
> >>      > > 971 28, Luleå, Sweden
> >>      > >
> >>      > > Phone [phone] <tel:%2B46-1071%2043042>
> >>      > >
> >>      > > SMS/MMS [phone] <tel:%2B46-73%20078%203289>
> >>      > >
> >>      > > [e-mail]
> >>     <mailto:[e-mail]>
> >>      > >
> >>      > > www.ericsson.com <http://www.ericsson.com>
> >>
> >>      > >
> >>      > >
> >>      > >
> >>      > > “The difference between stupidity and
> >>      > >
> >>      > > genius is that genius has its limits."
> >>      > > Albert Einstein
> >>      > > =================================
> >>      > >
> >>      > >
> >>      > >
> >>      > >
> >>      > >
> >>      > >
> >>      > > _______________________________________________
> >>      > > iccrg mailing list
> >>      > > [e-mail] <mailto:[e-mail]>
> >>
> >>      > > https://www.irtf.org/mailman/listinfo/iccrg
> >>      > >
> >>      >
> >>      >
> >>      >
> >>      > --
> >>      > Dave Täht
> >>      >
> >>      > NSFW:
> >>      >
> >>
> >>
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indec
> >>      > ent.article
> >>     _______________________________________________
> >>     iccrg mailing list
> >>     [e-mail] <mailto:[e-mail]>
> >>     https://www.irtf.org/mailman/listinfo/iccrg____
> >>
> >>     __ __
> >>
> >>
> >
> > --
> >
> > Zahed
> >
> > ==================================================
> > ANM ZAHEDUZZAMAN SARKER
> >
> >
> > Ericsson AB
> > Services, Media and Network Features
> > Laboratoriegränd 11
> > 97128 Luleå, Sweden
> > Phone [phone]
> > Fax [phone]
> > SMS/MMS [phone]
> > [e-mail]
> > www.ericsson.com
> >
> > ==================================================
> 
> 
> 
> --
> Dave Täht
> 
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indec
> ent.article