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

Tim Panton <tim@phonefromhere.com> Mon, 19 September 2011 08:19 UTC

Return-Path: <tim@phonefromhere.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 4BA5021F8B2E for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 01:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 ts+7tt1clEIo for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 01:19:06 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 77B2021F8B28 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 01:19:06 -0700 (PDT)
Received: from [10.14.26.192] (095-097-078-010.static.chello.nl [95.97.78.10]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id EE27E37A902; Mon, 19 Sep 2011 09:34:17 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <4E76F544.1040108@jesup.org>
Date: Mon, 19 Sep 2011 09:21:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.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>
To: Randell Jesup <randell-ietf@jesup.org>
X-Mailer: Apple Mail (2.1244.3)
Cc: 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 08:19:07 -0000

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.