Re: [rtcweb] Congestion Control proposal

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 07 October 2011 18:59 UTC

Return-Path: <bernard_aboba@hotmail.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 726EA21F8BC4 for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 11:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPtenWW9Ynnv for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 11:59:09 -0700 (PDT)
Received: from blu0-omc4-s24.blu0.hotmail.com (blu0-omc4-s24.blu0.hotmail.com [65.55.111.163]) by ietfa.amsl.com (Postfix) with ESMTP id 39CB421F8678 for <rtcweb@ietf.org>; Fri, 7 Oct 2011 11:59:08 -0700 (PDT)
Received: from BLU152-W31 ([65.55.111.135]) by blu0-omc4-s24.blu0.hotmail.com 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: [131.107.0.117]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <randell-ietf@jesup.org>, <rtcweb@ietf.org>
Date: Fri, 7 Oct 2011 12:02:21 -0700
Importance: Normal
In-Reply-To: <4E8E35C4.3000509@jesup.org>
References: <4E8DCA06.5060506@jesup.org> <4E8E3005.3090307@mti-systems.com>, <4E8E35C4.3000509@jesup.org>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Oct 2011 19:02:22.0425 (UTC) FILETIME=[A4ED0C90:01CC8523]
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 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.