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&#39;s mailing list.
>
>
>

-- 
Randell Jesup
randell-ietf@jesup.org