Re: [rtcweb] Congestion Control proposal

Bernard Aboba <> Fri, 07 October 2011 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 726EA21F8BC4 for <>; Fri, 7 Oct 2011 11:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UPtenWW9Ynnv for <>; Fri, 7 Oct 2011 11:59:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 39CB421F8678 for <>; Fri, 7 Oct 2011 11:59:08 -0700 (PDT)
Received: from BLU152-W31 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 12:02:22 -0700
Message-ID: <BLU152-W31CA20D608753358E3D96093FE0@phx.gbl>
Content-Type: multipart/alternative; boundary="_f976257a-5d7f-41c2-8324-4834c9454a4a_"
X-Originating-IP: []
From: Bernard Aboba <>
To: <>, <>
Date: Fri, 7 Oct 2011 12:02:21 -0700
Importance: Normal
In-Reply-To: <>
References: <> <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Oct 2011 19:02:22.0425 (UTC) FILETIME=[A4ED0C90:01CC8523]
Subject: Re: [rtcweb] Congestion Control proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Oct 2011 18:59:10 -0000

> > I can't claim to fully understand the intended architecture from the
> > description in this email, but something struck me as odd when in one
> > breath it seems like data is flowing over TCP or SCTP (layered over
> > UDP) and in another there's a separate algorithm (the Google one, or
> > some modification) running for estimating bandwidth. Those seem
> > mutually exclusive to me, unless I completely misunderstand the goal
> > (which is entirely possible).

[BA] In practice, I think the concern is largely over UDP-based traffic. 
For TCP or SCTP  traffic, the native congestion control mechanisms should
be sufficient. 

> 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?  

> If we can make them work together or at least be respectful of each 
> other to avoid "fighting", that would be better.   

> The app may be able to help us by indicated the type of data to be transferred and the relative 
> priority of it.  (Background file transfers might stick to a small 
> percentage of the bandwidth unless bandwidth is very high; a game may 
> give priority to one stream of data over both media and other data 
> streams - it's unclear currently if we'll be able to support that, but 
> it would be nice.)

[BA] Agree. For example, if we're talking about a high-twitch game, 
you might want different behavior than for one where the datagram
channel needs more reliability.  

> Reporting changes to the application is another matter with its own
> challenges in either case, since the way the application responds will
> limit what the CC can do afterwards (without additional probing).

[BA] Yes.  

> 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?

> 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. 

> 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.