Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)

Henrik Lundin <hlundin@google.com> Tue, 20 September 2011 05:56 UTC

Return-Path: <hlundin@google.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 8FDCC21F888A for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 22:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.092
X-Spam-Level:
X-Spam-Status: No, score=-105.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 kCND87gSeeIT for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 22:56:29 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id ECFF621F85D1 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 22:56:28 -0700 (PDT)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p8K5wqnM025955 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 22:58:52 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316498333; bh=u1INRmnk5CMLoweCkz01drMcz7E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=CD6O4XhJ8e3mIizOmsheJvPeA7oAI968TSiMWjqL+QsoiqlbsXaNUaq5W5NHsIuQl wcfIE/mgpHbkYuvlMdj8w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=Fe1wMQw8rLHuIS24Gp8PV53uH2UKGeSCoofia3DGuWr7rZ7ZnixYT1PbplKcUhxhZ 3Qjd49lxo3BpLAIweZr5w==
Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by hpaq1.eem.corp.google.com with ESMTP id p8K5wol9018399 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Mon, 19 Sep 2011 22:58:51 -0700
Received: by gxk22 with SMTP id 22so145254gxk.30 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 22:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2TvMISDOn7Ek7slSW1mpcnz8hZ8t5UBkiBZfdVaVza0=; b=pCuy7S5314Cof/ylsH28hSdW8FoO/VhVwHDak2dnu9o5gc2QODitGMt1tUlTUfT4gt wE3NZO2rTrft7Izvglkg==
Received: by 10.100.56.25 with SMTP id e25mr288115ana.70.1316498330043; Mon, 19 Sep 2011 22:58:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.56.25 with SMTP id e25mr288109ana.70.1316498329898; Mon, 19 Sep 2011 22:58:49 -0700 (PDT)
Received: by 10.100.166.9 with HTTP; Mon, 19 Sep 2011 22:58:49 -0700 (PDT)
In-Reply-To: <CAKkvrEkx0mqnDWqNYse3r9WUMbYKNZhrBqQ0SPUAnTtKrA5bLg@mail.gmail.com>
References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <CAEdus3LcjV9x+gLdZm5vwKhh-ge6xzfWSEB_NxcHe1Gz_5DZ8g@mail.gmail.com> <CAOhzyf=MqsgsGUi521oJ5N6+T+K1N01MjeHYPpX_VZK8uyQksw@mail.gmail.com> <CAKkvrEkx0mqnDWqNYse3r9WUMbYKNZhrBqQ0SPUAnTtKrA5bLg@mail.gmail.com>
Date: Tue, 20 Sep 2011 07:58:49 +0200
Message-ID: <CAOhzyf=_n3VhNi1GgxdKJpyzEMLORcKX2499+YZHQnGqYURxjg@mail.gmail.com>
From: Henrik Lundin <hlundin@google.com>
To: Soo-Hyun Choi <soohyun.choi@cl.cam.ac.uk>
Content-Type: multipart/alternative; boundary=0016e647661c4d0dd404ad592794
X-System-Of-Record: true
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
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, 20 Sep 2011 05:56:30 -0000

On Tue, Sep 20, 2011 at 7:37 AM, Soo-Hyun Choi <soohyun.choi@cl.cam.ac.uk>wrote;wrote:

> A question and a suggestion.
>
>
>
> >>>>
> >>>> 4. Section 4.
> >>>>
> >>>> "This algorithm is run every time a receive report arrives at the
> >>>>    sender, which will happen [[how often do we expect? and why?]].  If
> >>>>    no receive report is recieved within [[what timeout?]], the
> algorithm
> >>>>    will take action as if all packets in the interval have been lost.
> >>>>    [[does that make sense?]]"
> >>>>
> >>>> The transmission of receiver reports is highly dependent on RTP
> profile,
> >>>> the RTCP bandwidth, trr-int parameter and any feedback events.
> >>>>
> >>>> If I start with assuming AVPF which seems reasonable in most browser
> to
> >>>> browser case with our current proposals for RTP support. Then if there
> >>>> are no feedback events the transmission of receiver reports will occur
> >>>> as often as the bandwidth allows, but no more often than the value of
> >>>> trr-int parameter.
> >>>>
> >>>> Here is might be worth mentioning that I do expect trr-int to be set
> to
> >>>> avoid RTCP reporting to often due to the relatively high RTCP
> bandwidth
> >>>> values that will be set due to the multiplexing of audio and video in
> a
> >>>> single RTP session. Thus avoiding that RTCP rates are as high or
> larger
> >>>> than the audio streams they report in steady state.
> >>>
> >>> Agreed.  This is where my plans to suggest a baseline algorithm that
> >>> melds
> >>> the reception data of all the streams in the PeerConnection may be a
> >>> significant advantage over doing bandwidth estimation on each stream
> >>> independently.  We'll see if I can make the idea work, but there are
> some
> >>> significant advantages if it does.  If not, we can estimate in each
> >>> channel
> >>> independently as per the Google algorithm.
> >>>
> >>> You can also use rtcp-fb PLI/etc events to hang these reports off of,
> >>> increasing
> >>> the frequency they get through with minimal extra bandwidth use.
> >>>
> >>>
> >>>> When feedback events occur the stack will have the choice of sending a
> >>>> RTCP RR, that is a choice provided due to the reduced size RTCP
> >>>> specification included. But if the loss cumulative count diff is
> >>>> non-zero it might be worth mandating that the RR/SR is included in any
> >>>> such feedback RTCP packet.
> >>>
> >>> Exactly - or a TMMBR with the results of the receiver-side bandwidth
> >>> calculations.
> >>>
> >>>> For that reason causing a feedback event when there is losses and
> >>>> schedule them using the early algorithm may be a good choice to ensure
> >>>> timely reporting of any loss.
> >>>>
> >>>> If one uses AVP then the RTCP timing rules will give you when you
> >>>> transmit RTCP feeedback and thus the parameterization becomes central
> >>>> here. A clear issue is if people uses the minimal interval of 5
> seconds
> >>>> or the 360/Session_BW(in kbps). I would note that 5 seconds is very
> long
> >>>> in adaptation situations.
> >>>
> >>> Yes.
> >
> > In the proposed algorithm, the RTCP interval adds to the system response
> > time. The response time governs the bandwidth increase rate so that the
> step
> > into over-use will have a limited delay build-up before it can be
> detected
> > and mitigated. Thus, a long RTCP interval results in a slow adaptation,
> but
> > it should still be stable.
> >
>
> I wonder how would you guarantee that such a long RTCP interval
> doesn't result in instability when estimating bandwidth? Typically, a
> delay-based CC algorithm can be vulnerable when timer become
> inacurate. I suspect the delayed RTCP feedback can calculate available
> bandwidth correctly. Why not use per-packet based feedback (using
> AVPF, for example) in order not to cause any harm with this kind of
> situation?
>
I agree that more frequent feedback does improve the bandwidth estimation.
No doubt about that.


> I would think that a CC mechanism, at least, should be able to
> calculate and suggest right/correct rate to the upper layer's codec so
> that it could determine whether it actually increase/decrease encoding
> rate or not, depending upon CC's suggested rate.
>
>
> Kind regards,
> Soo-Hyun
>



-- 
Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41