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

[Tim Panton <[e-mail]>]

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.