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

Varun Singh <vsingh.ietf@gmail.com> Thu, 26 June 2014 13:18 UTC

Return-Path: <vsingh.ietf@gmail.com>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF15E1B2FD3 for <rmcat@ietfa.amsl.com>; Thu, 26 Jun 2014 06:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcSYb31T0VnO for <rmcat@ietfa.amsl.com>; Thu, 26 Jun 2014 06:18:34 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5E81B3004 for <rmcat@ietf.org>; Thu, 26 Jun 2014 06:11:34 -0700 (PDT)
Received: by mail-ig0-f172.google.com with SMTP id hn18so678492igb.17 for <rmcat@ietf.org>; Thu, 26 Jun 2014 06:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tpk8S6jt2jjSdOnhebH0VmgZfqwHiB6wjGpSOtdddws=; b=IMr4frxyjNCfYKL9oHSKoCKAR2hRW2iASspogjAiATOavySxw2AhCvzZX4SUoff4mp QFjiAJIiyVX2rd8aJJICE3Zcfgu2JVY696cu0EpxqUkjrt17IXtDR71BJ7chf/Tmk8oy FtPevnBHQEgefw0JuyJQpXRL+AOtcOY5NdWsRbpAv0yuMIe1KDGRk8IHGIuq0MyGx172 Z9/delo6JDVaofPA0oFi6jjDGAH4YI8skSAeP9lIeQ4Fn1KFrsyiUr0sEolb06hQ+skg rsuJPCd5mH/NhRfv9Y6yCxQYyWESZxA3XJ5aDFXsH+aR/EIq3GiP5QcC5uHOyFUpcnlJ owpA==
MIME-Version: 1.0
X-Received: by 10.42.12.76 with SMTP id x12mr1649735icx.96.1403788293738; Thu, 26 Jun 2014 06:11:33 -0700 (PDT)
Received: by 10.50.119.38 with HTTP; Thu, 26 Jun 2014 06:11:33 -0700 (PDT)
Received: by 10.50.119.38 with HTTP; Thu, 26 Jun 2014 06:11:33 -0700 (PDT)
In-Reply-To: <53AC0DC9.2020803@ericsson.com>
References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> <CAA93jw5quLK6w8r43vPFf0FMH_XCxysPwzgMDzrQtv=JBRjf=Q@mail.gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA31F9F56B@ESESSMB205.ericsson.se> <CACHLvedAdFYgKdyzx6sw01_d9XHgzKVNXkChAFRB-jZpiGppfg@mail.gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA31FA50F7@ESESSMB205.ericsson.se> <CACHLvecxtG++buc9M7EVEdH_M4_Fcm-pQegVT0B8-THUHiwV8g@mail.gmail.com> <53AC0DC9.2020803@ericsson.com>
Date: Thu, 26 Jun 2014 16:11:33 +0300
Message-ID: <CAEbPqry4xvpgTAkUhA4d4ZfLp_0B=58ZP2fRp=57kSrUiMELXg@mail.gmail.com>
From: Varun Singh <vsingh.ietf@gmail.com>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
Content-Type: multipart/alternative; boundary="20cf301d40ce9695d604fcbcee36"
Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/DyNFUcd03KN1vxNJOrH94O4XOdM
Cc: "rmcat WG (rmcat@ietf.org)" <rmcat@ietf.org>
Subject: Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 13:18:41 -0000

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" <
zaheduzzaman.sarker@ericsson.com> 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
>> <ingemar.s.johansson@ericsson.com
>> <mailto:ingemar.s.johansson@ericsson.com>> 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:ldecicco@gmail.com
>>     <mailto:ldecicco@gmail.com>]
>>     *Sent:* den 25 juni 2014 13:23
>>     *To:* Ingemar Johansson S
>>     *Cc:* Dave Taht; iccrg@irtf.org <mailto:iccrg@irtf.org>
>>     *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:ingemar.s.johansson@ericsson.com>> 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:dave.taht@gmail.com
>>     <mailto:dave.taht@gmail.com>]
>>      > Sent: den 17 juni 2014 20:00
>>      > To: Ingemar Johansson S
>>      > Cc: iccrg@irtf.org <mailto:iccrg@irtf.org>
>>      > 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:ingemar.s.johansson@ericsson.com>> 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 +46-1071 43042 <tel:%2B46-1071%2043042>
>>      > >
>>      > > SMS/MMS +46-73 078 3289 <tel:%2B46-73%20078%203289>
>>      > >
>>      > > ingemar.s.johansson@ericsson.com
>>     <mailto:ingemar.s.johansson@ericsson.com>
>>      > >
>>      > > www.ericsson.com <http://www.ericsson.com>
>>      > >
>>      > >
>>      > >
>>      > > “The difference between stupidity and
>>      > >
>>      > > genius is that genius has its limits."
>>      > > Albert Einstein
>>      > > =================================
>>      > >
>>      > >
>>      > >
>>      > >
>>      > >
>>      > >
>>      > > _______________________________________________
>>      > > iccrg mailing list
>>      > > iccrg@irtf.org <mailto:iccrg@irtf.org>
>>      > > 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
>>     iccrg@irtf.org <mailto:iccrg@irtf.org>
>>     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 +46 10 717 37 43
> Fax +46 920 996 21
> SMS/MMS +46 76 115 37 43
> zaheduzzaman.sarker@ericsson.com
> www.ericsson.com
>
> ==================================================
>
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg
>
>