Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; Mon, 19 Sep 2011 22:58:51 -0700 Received: by gxk22 with SMTP id 22so145254gxk.30 for ; 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: References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> Date: Tue, 20 Sep 2011 07:58:49 +0200 Message-ID: From: Henrik Lundin To: Soo-Hyun Choi Content-Type: multipart/alternative; boundary=0016e647661c4d0dd404ad592794 X-System-Of-Record: true Cc: Randell Jesup , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 05:56:30 -0000 --0016e647661c4d0dd404ad592794 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 20, 2011 at 7:37 AM, Soo-Hyun Choi 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 --0016e647661c4d0dd404ad592794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 20, 2011 at 7:37 AM, Soo-Hyu= n Choi <s= oohyun.choi@cl.cam.ac.uk> wrote:
A question and a suggestion.



>>>>
>>>> 4. Section 4.
>>>>
>>>> "This algorithm is run every time a receive report ar= rives at the
>>>> =A0 =A0sender, which will happen [[how often do we expect?= and why?]]. =A0If
>>>> =A0 =A0no receive report is recieved within [[what timeout= ?]], the algorithm
>>>> =A0 =A0will take action as if all packets in the interval = have been lost.
>>>> =A0 =A0[[does that make sense?]]"
>>>>
>>>> The transmission of receiver reports is highly dependent o= n RTP profile,
>>>> the RTCP bandwidth, trr-int parameter and any feedback eve= nts.
>>>>
>>>> If I start with assuming AVPF which seems reasonable in mo= st browser to
>>>> browser case with our current proposals for RTP support. T= hen if there
>>>> are no feedback events the transmission of receiver report= s will occur
>>>> as often as the bandwidth allows, but no more often than t= he 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 R= TCP bandwidth
>>>> values that will be set due to the multiplexing of audio a= nd video in a
>>>> single RTP session. Thus avoiding that RTCP rates are as h= igh or larger
>>>> than the audio streams they report in steady state.
>>>
>>> Agreed. =A0This is where my plans to suggest a baseline algori= thm that
>>> melds
>>> the reception data of all the streams in the PeerConnection ma= y be a
>>> significant advantage over doing bandwidth estimation on each = stream
>>> independently. =A0We'll see if I can make the idea work, b= ut there are some
>>> significant advantages if it does. =A0If 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 us= e.
>>>
>>>
>>>> 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 d= iff is
>>>> non-zero it might be worth mandating that the RR/SR is inc= luded in any
>>>> such feedback RTCP packet.
>>>
>>> Exactly - or a TMMBR with the results of the receiver-side ban= dwidth
>>> calculations.
>>>
>>>> For that reason causing a feedback event when there is los= ses and
>>>> schedule them using the early algorithm may be a good choi= ce to ensure
>>>> timely reporting of any loss.
>>>>
>>>> If one uses AVP then the RTCP timing rules will give you w= hen you
>>>> transmit RTCP feeedback and thus the parameterization beco= mes 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 second= s is very long
>>>> in adaptation situations.
>>>
>>> Yes.
>
> In the proposed algorithm, the RTCP interval adds to the system respon= se
> time. The response time governs the bandwidth increase rate so that th= e step
> into over-use will have a limited delay build-up before it can be dete= cted
> 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 im= prove 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<= br> 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=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 646 13 = 41


--0016e647661c4d0dd404ad592794--