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

Soo-Hyun Choi <> Wed, 21 September 2011 07:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7799F21F848D for <>; Wed, 21 Sep 2011 00:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vRD+2TjJp5bZ for <>; Wed, 21 Sep 2011 00:57:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C3EBA21F8476 for <>; Wed, 21 Sep 2011 00:57:07 -0700 (PDT)
Received: by wyh15 with SMTP id 15so2566012wyh.27 for <>; Wed, 21 Sep 2011 00:59:35 -0700 (PDT)
Received: by with SMTP id eo15mr367369wbb.2.1316591975057; Wed, 21 Sep 2011 00:59:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 21 Sep 2011 00:59:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Soo-Hyun Choi <>
Date: Wed, 21 Sep 2011 16:59:15 +0900
Message-ID: <>
To: Harald Alvestrand <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
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: Wed, 21 Sep 2011 07:57:09 -0000


>> One of the critical metrics of a delay-based CC algo is an accurate
>> measurement of inter-packet interval (IPI) and timely report of IPI to
>> the sender so it can update the send rate correctly, which we all
>> agreed in this email thread. Although everyone in this list seemed to
>> aware of this, I have highlighted again that the relatively
>> course-grained RTCP carrying the IPI measurement data can cause
>> instability at the encoder's output bitrate due to the following
>> reason.
> The draft's suggestion is to avoid the need for communicating all the IPI
> information from the receiver to the sender by doing part of the processing
> and estimation at the receiver. I think we need to send the resulting
> information quickly when it changes, but don't need to send it so often when
> it remains stable. What "quickly" means in this context is a good question -
> 0.1 second? 1 second? Certainly less than 5 seconds?

Sure - one may not need to send the receiver report every so often
when network is stable. But the question is "how long stable is
stable?". Perhaps, the definition of "stable" might fall into
unquantifiable term, too? Anyway, when I said "quickly", I meant "at
least once in an every RTT" (borrowing from the TCP SACK analogy), in
which the use of the standard RTCP RR is not suitable in this level of

>> I would like to ask to this list (or Harald) if suggesting alternative
>> CC algo idea could fit into the RTCWEB Charter's scope - if so, I
>> could elaborate more by writing an I-D or so. In the mean time, you
>> could check my document at if you are
>> interested.
> I am certainly looking for input on where we can best have this discussion,
> too!
> Algorithm design is outside of RTCWEB's charter, but I think
> requirements/criteria for what "good enough" means for RTCWEB is inside it.

Question: Isn't your draft also proposing a new CC mechanism in the
context of RTCWEB?

Kind regards,