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

[Varun Singh <[e-mail]>]

Hi,

On Mon, Sep 19, 2011 at 11:29, Henrik Lundin <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> Henrik Lundin | WebRTC Software Eng | [e-mail] | [phone]
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>



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