Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)

Varun Singh <vsingh.ietf@gmail.com> Mon, 19 September 2011 13:13 UTC

Return-Path: <vsingh.ietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFF921F8BB8 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 06:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.378
X-Spam-Level:
X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYf+CR0Vn2go for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 06:13:08 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B559A21F8BA4 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 06:13:07 -0700 (PDT)
Received: by fxd18 with SMTP id 18so4291421fxd.31 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 06:15:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=lB1PL5+sjppWW9r7dwWsyvHc43JeY7Uq7CACeEjfBw8=; b=E7CaCb4NxwrA3mTsEuj6e8pZhR8utsVeubsGyZNO3krhPDUsxqq+StWq08FS6H8VaW lRMMlvQPEM2BvaxmZOk5XbppRh5bdwdG6UJcSHWWdUQv3mAVJwHjMenuBM6XVGvKm29d 3SrlrcR/yOIRLuzvHbM6ABkNYZnXLe9qC4glw=
Received: by 10.223.49.213 with SMTP id w21mr5187533faf.44.1316438130189; Mon, 19 Sep 2011 06:15:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.4.136 with HTTP; Mon, 19 Sep 2011 06:15:10 -0700 (PDT)
In-Reply-To: <CAOhzyfkXh=d2Ayd8YU0E8sgO7sxpP-=vD0P4NXpmB75PBza7tw@mail.gmail.com>
References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <CAEdus3LcjV9x+gLdZm5vwKhh-ge6xzfWSEB_NxcHe1Gz_5DZ8g@mail.gmail.com> <4E76F544.1040108@jesup.org> <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.com> <CAOhzyfkXh=d2Ayd8YU0E8sgO7sxpP-=vD0P4NXpmB75PBza7tw@mail.gmail.com>
From: Varun Singh <vsingh.ietf@gmail.com>
Date: Mon, 19 Sep 2011 16:15:10 +0300
Message-ID: <CAEbPqrzHNb02z+QPTWiFYyqy0ewUTBpPq+p1y7rUY=ULkTF42Q@mail.gmail.com>
To: Henrik Lundin <hlundin@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 13:13:09 -0000

Hi,

On Mon, Sep 19, 2011 at 11:29, Henrik Lundin <hlundin@google.com> wrote:
> Tim,
> The problem that we are trying to attack with the proposal is perhaps better
> described as "available bandwidth estimation" rather than congestion
> control. I _would_ like to try and separated it from codecs. The bandwidth
> estimator should inform the sender of the current feasible rate between two
> endpoints, and it should then be up to the sending client (application,
> codecs, channel coding, etc) to figure out a way to stay within that limit,
> while maintaining an acceptable quality for the use-case at hand.
> /Henrik
>

I would agree that the sending application+codec should decide what
trade-off it wants to make, if any. However, it should still be open
to discussion if the congestion control is a sender driven (e.g. TFRC)
or receiver driven (e.g. TMMBR) or a combination of sender and
receiver driven.

>
> On Mon, Sep 19, 2011 at 10:21 AM, Tim Panton <tim@phonefromhere.com> wrote:
>>
>> On 19 Sep 2011, at 08:54, Randell Jesup wrote:
>>
>> > Open question to the list: should the congestion-control-geeks discuss
>> > here on the
>> > list the nitty-gritty details required to build the requirements and
>> > especially to design
>> > and debate a possible proposed "baseline" congestion-control algorithm?
>> >
>> > We can certainly do that detailed discussion by email and come back with
>> > a
>> > draft;  I had been planning to do it by email, but recent discussion on
>> > rtcweb
>> > made me think I should ask for opinions on this.  Given the structure,
>> > if there's
>> > any significant support for "on-the-list" I'll do that.  Realize though
>> > that they may
>> > get pretty long and detailed without really touching on the larger
>> > issues being
>> > discussed here.
>> >
>> > Right now the bof members to discuss this and propose a draft would be
>> > myself,
>> > Harald, Justin,  Stefan Holmer and Magnus.
>> >
>>
>> I'd like to lurk  on any BoF list, if I may,
>> but I have a feeling that congestion control isn't quite such a
>> self-contained problem
>> as forming a BoF list might imply.
>>
>> Roughly, my argument is that any modern congestion control for RTC needs
>> to involve the application
>> and the codec.
>>
>> Here's an example:
>>        I'm in a video conference with 4 other people and I'm exceeding the
>> available downlink
>> bandwidth. What I want is that the video degrades (framerate of quality)
>> without _any_ degradation
>> of the video. I might even want to drop all the video but keep the audio
>> and screenshare alive.
>>        Conversely if I'm watching an ice hockey game - I'd rather lose
>> audio quality than frame-rate.
>>
>> But in _both_ cases I'd like the app to try and tweak the encoder params
>> to get within the available bandwidth
>> before we start injecting delay or dropping frames.
>>
>> So my proposal is that the web app is given a chance to get within the
>> available bandwidth
>> before the system starts putting hard constraints on the RTP level.
>>
>> All of which makes it something we need to discuss in a holistic fashion
>> with the rest of the API.
>>
>> Tim.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>



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