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

[Zaheduzzaman Sarker <[e-mail]>]

Hi Varun,

No, it does not.

BR

Zahed

On 2014-06-26 15:11, Varun Singh wrote:
> Hi Zahed,
>
> Does your GCC simulation code implement any FEC or Retx? Since the gcc
> draft does not imply use of any repair mechanism even though the chrome
> browser implements both.
>
> On 26 Jun 2014 14:11, "Zaheduzzaman Sarker"
> <[e-mail]
> <mailto:[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.
>
>     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
>     <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
>     <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
>         <ingemar.s.johansson@ericsson.__com
>         <mailto:[e-mail]>
>         <mailto:ingemar.s.johansson@__ericsson.com
>         <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]>
>              <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]>
>         <mailto:[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
>              <ingemar.s.johansson@ericsson.__com
>         <mailto:[e-mail]>
>              <mailto:ingemar.s.johansson@__ericsson.com
>         <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]>
>              <mailto:[e-mail] <mailto:[e-mail]>>]
>               > Sent: den 17 juni 2014 20:00
>               > To: Ingemar Johansson S
>               > Cc: [e-mail] <mailto:[e-mail]>
>         <mailto:[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
>               > <ingemar.s.johansson@ericsson.__com
>         <mailto:[e-mail]>
>              <mailto:ingemar.s.johansson@__ericsson.com
>         <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
>         <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>
>         <tel:%2B46-1071%2043042>
>               > >
>               > > SMS/MMS [phone] <tel:%2B46-73%20078%203289>
>         <tel:%2B46-73%20078%203289>
>               > >
>               > > ingemar.s.johansson@ericsson.__com
>         <mailto:[e-mail]>
>              <mailto:ingemar.s.johansson@__ericsson.com
>         <mailto:[e-mail]>>
>               > >
>               > > www.ericsson.com <http://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]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>               > > https://www.irtf.org/mailman/__listinfo/iccrg
>         <https://www.irtf.org/mailman/listinfo/iccrg>
>               > >
>               >
>               >
>               >
>               > --
>               > Dave Täht
>               >
>               > NSFW:
>               >
>         https://w2.eff.org/Censorship/__Internet_censorship_bills/__russell_0296_indec
>         <https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indec>
>               > ent.article
>              _________________________________________________
>              iccrg mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.irtf.org/mailman/__listinfo/iccrg____
>         <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] <tel:%2B46%2010%20717%2037%2043>
>     Fax [phone] <tel:%2B46%20920%20996%2021>
>     SMS/MMS [phone] <tel:%2B46%2076%20115%2037%2043>
>     zaheduzzaman.sarker@ericsson.__com
>     <mailto:[e-mail]>
>     www.ericsson.com <http://www.ericsson.com>
>
>     ==============================__====================
>
>     _______________________________________________
>     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

==================================================