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

[Varun Singh <[e-mail]>]

Hi Luca,

My implementation of GCC was based on:
http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02
(spring/summer 2012) and earlier, which didn't yet contain the text
relating to processing multiple streams from a single endpoint. This
had me wondering for a moment on how to incorporate these streams into
GCC. With the addition of the RTP to NTP time conversion, the GCC
arrival filter can work across timestamps from repair, audio and video
packets.

Cheers,
Varun

On Thu, Jun 26, 2014 at 4:38 PM, Luca De Cicco <[e-mail]> wrote:
> Dear Varun,
>
> the way RTX or FEC are computed shouldn't impact GCC sending rate dynamics,
> but only
> the user's QoE.
>
> Cheers,
> Luca
>
> On Thu, Jun 26, 2014 at 3:11 PM, Varun Singh <[e-mail]> 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]> 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.
>>>
>>> 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
>>>
>>> ==================================================
>>>
>>> _______________________________________________
>>> iccrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/iccrg
>>>
>



-- 
http://www.netlab.tkk.fi/~varun/