Re: [rtcweb] Congestion Control proposal

Randell Jesup <randell-ietf@jesup.org> Fri, 07 October 2011 21:08 UTC

Return-Path: <randell-ietf@jesup.org>
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 B149021F8C44 for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 14:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level:
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.026, 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 Pmc3ni8M3Hys for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 14:08:43 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD0D21F8C32 for <rtcweb@ietf.org>; Fri, 7 Oct 2011 14:08:42 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RCHi0-0003Wn-Rh for rtcweb@ietf.org; Fri, 07 Oct 2011 16:11:56 -0500
Message-ID: <4E8F6A26.6020407@jesup.org>
Date: Fri, 07 Oct 2011 17:07:50 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E8DCA06.5060506@jesup.org> <4E8E3005.3090307@mti-systems.com>, <4E8E35C4.3000509@jesup.org> <BLU152-W31CA20D608753358E3D96093FE0@phx.gbl>
In-Reply-To: <BLU152-W31CA20D608753358E3D96093FE0@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Congestion Control proposal
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: Fri, 07 Oct 2011 21:08:43 -0000

On 10/7/2011 3:02 PM, Bernard Aboba wrote:
>  > The fallback/simplest model would be to just consider the data channels
>  > under SCTP and the media channels to be separate flows, and let them
>  > fight for bandwidth as normal.
>
> [BA] There are multiple concerns here. One was about DoS attacks, which
> was about having the recipient confirm the desired bandwidth. That's
> what Harald mentioned.
>
> The other issue is congestion control/codec adaptation (e.g. responding
> to RFC 3714 concerns). While I understand the need for this on the
> datagram channel, with respect to congestion control of RTP traffic, won't
> adaptation be codec-specific? If the codec doesn't adapt (e.g. G.711) or
> does so based on RTCP feedback, how would an additional congestion
> control mechanism work?

This (this proposal) is the mechanism which will tell the sender to 
adapt their codec settings (video encoder bitrate, etc).

>  > Don't forget that we normally will have a media channel active, and if
>  > video is being sent (and to a lesser extent audio, especially if we're
>  > using Opus) that media channel is adaptive and can adapt upwards to find
>  > the limits of bandwidth.
>
> [BA] Yes, it can but today that adaption is typically based on RTCP, right?

Not on traditional SR/RR RTCP sub-packets, but on AVPF Feedback 
messages; either a variant of TMMBR (if we do all the bandwidth 
calculations in the client), or a message where we feed back cooked 
arrival statistics to the sender via a new Feedback message.  If we 
don't get this info from the receiver we'll fall back to classic 
RR/SR-based adaptation, which sucks.  Doable, but sucks (especially if 
you only get a report average every 5 seconds).

>  > Decisions like that are tough or impossible for webrtc to make on it's
>  > own because it doesn't have the context of the application to guide it.
>
> [BA] The problem is that handling the events correctly will also probably be
> outside the capability of your average application developer. So enabling
> reasonable things to happen by default is probably a practical requirement.

We'll definitely supply or apply defaults, and if the application 
doesn't choose we'll handle it for them.  We may have some hinting to 
guide our default adaptation (relative priorities).

>  > That said, the interface and parameters and style for interacting with
>  > the JS app is the thing this posting is weakest on, since I'm not
>  > well-versed in the common API paradigms that JS app developers expect,
>  > and I'd love proposals for how we expose these choices and information
>  > to the app.
>
> [BA] The problem in my mind is whether we're really expecting RTCWEB
> Codecs do something with the additional information provided.

You should read Harald's draft for the base algorithm that we'll be 
modifying to provide this.  The base algorithm is from a very good class 
of low-delay congestion control algorithms, based on bottleneck router 
bufferstate sensing:

http://www.ietf.org/id/draft-alvestrand-rtcweb-congestion-00.txt

-- 
Randell Jesup
randell-ietf@jesup.org