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

[Henrik Lundin <[e-mail]>]

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



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]