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, 07 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.
- Re: [rtcweb] Congestion Control proposal Randell Jesup
- Re: [rtcweb] Congestion Control proposal Randell Jesup
- Re: [rtcweb] Congestion Control proposal Randell Jesup
- Re: [rtcweb] Congestion Control proposal Colin Perkins
- [rtcweb] Congestion Control proposal Randell Jesup
- Re: [rtcweb] Congestion Control proposal Wesley Eddy
- Re: [rtcweb] Congestion Control proposal Bernard Aboba
- Re: [rtcweb] Congestion Control proposal Colin Perkins
- Re: [rtcweb] Congestion Control proposal Randell Jesup