Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
Randell Jesup <randell-ietf@jesup.org> Tue, 06 September 2011 22:22 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 A1BD421F8EE1 for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 15:22:47 -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 kdwRpKVb4ZZp for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 15:22:46 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id AB47E21F8EDF for <rtcweb@ietf.org>; Tue, 6 Sep 2011 15:22:46 -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 1R144H-0000U6-Kt for rtcweb@ietf.org; Tue, 06 Sep 2011 17:24:33 -0500
Message-ID: <4E669CF6.3030708@jesup.org>
Date: Tue, 06 Sep 2011 18:21:42 -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: <4E649FBD.1090001@alvestrand.no>
In-Reply-To: <4E649FBD.1090001@alvestrand.no>
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] 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: Tue, 06 Sep 2011 22:22:47 -0000
On 9/5/2011 6:09 AM, Harald Alvestrand wrote: > There is a congestion control algorithm inside the Google WebRTC > codebase that hasn't been documented publicly before, and might be > interesting as input when we get around to discussing what congestion > control should be mandatory-to-implement in this group. Where is this in the webrtc drop? I looked but didn't see anything hooked up to RTPReceiverVideo::EstimateBandwidth(). There's something in this genre for iSAC, though I didn't have time to look closely but it appears to be somewhat specialized for iSAC. > > It's not forwarded as a candidate for what the result should be; I > think there can be better solutions (see the "further work" section in > this draft). Harald et al: this definitely answers my suggestion/request that we make congestion control mandatory, and that we target something similar to Radvision's NetSense, which this appears to have similar characteristics to. A few comments: In 3. (Receiver-side): When an over-use is detected the system transitions to the decrease state, where the available bandwidth estimate is decreased to a factor times the currently incoming bit rate. A_hat(i) = alpha*R_hat(i) alpha is typically chosen to be in the interval [0.8, 0.95]. May I suggest that there's more information available here than a single bit of "over-bandwidth". We have an estimate here how *much* we're over-bandwidth, though cross-traffic and other fixed streams (audio) are part of that too, so it needs to be used with a grain of salt - but that slope is useful information. In either case we want to measure the highest incoming rate during the under-use interval: R_max = max{R_hat(i)} for i in 1..K where K is the number of frames of under-use before returning to the normal state. R_max is a measure of the actual bandwidth available and is a good guess of what bit rate we should be able to transmit at. Therefore the available bandwidth will be set to Rmax when we transition from the hold state to the increase state. This is good, but it might make sense to explain why this is the case (as the draft does for other parts); I assume the argument is that if the delay is reducing after a bottleneck, then from the router that was buffering to us (usually just on the far end of the bottleneck) packets are flowing through from there as fast as they can. In fact, the rate they're getting through *while* you're over-bandwidth is actually the best estimate of total bandwidth you're likely to get. So in fact you can estimate it well in all cases except when you're in "increase" mode (buffers drained and stable), pretty much. I would also suggest that the rate to use is R_max * gamma (where gamma < 1.0) BTW, the description of directions here is confusing; the receiver is determining the apparent bandwidth the sender should be using; "we should be able to transmit at" is both wrong and confusing (probably should be "the sender should be able to transmit at"). Sender-side control: 10% seems rather high. My experience was more aggressive in the face of loss, both in the limit at which it reacts and the amount it reduces - over maybe 5% loss I would cut sender bandwidth by 10 or 15% on top of whatever the slope told me to do. Interop - the receiver could incorporate packet loss into the estimate used for TMMBR, which might improve talking to senders who don't follow this algorithm. We should consider how to handle cases that involve interop and if and how to detect them; the algorithm may want to be different for those cases. Future: We very much want to merge all the info we can from all the streams, so we can control where the bandwidth restrictions are applied instead of running it on N streams independently. (For example, if we're sending two video streams we may want to apportion the bandwidth according to their size/framerate instead of equally, and we'll very much want to consider for data channels (and perhaps media) a 'priority' factor ala RTFMP.) I'll have more comments, but I need to turn into a pumpkin now and wanted to get what I have on the wire. I haven't spent a lot of time fleshing them out or editing, so take them as a starting point for discussion. > > The code is available through www.webrtc.org, and the IPR statements > covering the code are found here: > https://sites.google.com/site/webrtc/license-rights > > Harald > > -------- Original Message -------- > Subject: New Version Notification for > draft-alvestrand-rtcweb-congestion-00.txt > Date: Mon, 05 Sep 2011 03:03:38 -0700 > From: internet-drafts@ietf.org > To: harald@alvestrand.no > CC: harald@alvestrand.no, holmer@google.com > > > > A new version of I-D, draft-alvestrand-rtcweb-congestion-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. > > Filename: draft-alvestrand-rtcweb-congestion > Revision: 00 > Title: A Google Congestion Control for Real-Time Communication on the World Wide Web > Creation date: 2011-09-05 > WG ID: Individual Submission > Number of pages: 14 > > Abstract: > This document describes two methods of congestion control when using > real-time communications on the World Wide Web (RTCWEB); one sender- > based and one receiver-based. > > It is published to aid the discussion on mandatory-to-implement flow > control for RTCWEB applications; initial discussion is expected in > the RTCWEB WG's mailing list. > > > -- Randell Jesup randell-ietf@jesup.org
- [rtcweb] An input for discussing congestion contr… Harald Alvestrand
- Re: [rtcweb] An input for discussing congestion c… Randell Jesup
- Re: [rtcweb] An input for discussing congestion c… Harald Alvestrand
- Re: [rtcweb] An input for discussing congestion c… Magnus Westerlund
- Re: [rtcweb] An input for discussing congestion c… Randell Jesup
- Re: [rtcweb] An input for discussing congestion c… Stefan Holmer
- Re: [rtcweb] An input for discussing congestion c… Randell Jesup
- Re: [rtcweb] An input for discussing congestion c… Henrik Lundin
- Re: [rtcweb] An input for discussing congestion c… Varun Singh
- Re: [rtcweb] An input for discussing congestion c… Henrik Lundin
- Re: [rtcweb] An input for discussing congestion c… Tim Panton
- Re: [rtcweb] An input for discussing congestion c… Henrik Lundin
- Re: [rtcweb] An input for discussing congestion c… Varun Singh
- Re: [rtcweb] An input for discussing congestion c… Randell Jesup
- Re: [rtcweb] An input for discussing congestion c… Soo-Hyun Choi
- Re: [rtcweb] An input for discussing congestion c… Henrik Lundin
- Re: [rtcweb] An input for discussing congestion c… Soo-Hyun Choi
- Re: [rtcweb] An input for discussing congestion c… Harald Alvestrand
- Re: [rtcweb] An input for discussing congestion c… Soo-Hyun Choi
- Re: [rtcweb] An input for discussing congestion c… Harald Alvestrand
- Re: [rtcweb] An input for discussing congestion c… Dzonatas Sol
- Re: [rtcweb] An input for discussing congestion c… Randell Jesup
- Re: [rtcweb] An input for discussing congestion c… Soo-Hyun Choi
- Re: [rtcweb] An input for discussing congestion c… Harald Alvestrand
- Re: [rtcweb] An input for discussing congestion c… Randell Jesup
- Re: [rtcweb] An input for discussing congestion c… Jim Gettys
- Re: [rtcweb] An input for discussing congestion c… Henrik Lundin
- Re: [rtcweb] An input for discussing congestion c… Ingemar Johansson S
- Re: [rtcweb] An input for discussing congestion c… Henrik Lundin
- Re: [rtcweb] An input for discussing congestion c… Randell Jesup
- Re: [rtcweb] An input for discussing congestion c… Stefan Holmer
- Re: [rtcweb] An input for discussing congestion c… Soo-Hyun Choi