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

[Dave Taht <[e-mail]>]

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_indecent.article