Re: [rtcweb] #25: Section 5.1 Conferencing Extensions

Magnus Westerlund <> Tue, 27 August 2013 06:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9249E21F99E1 for <>; Mon, 26 Aug 2013 23:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.652
X-Spam-Status: No, score=-105.652 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hTXXl6c6SBgb for <>; Mon, 26 Aug 2013 23:18:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6692F21F99DE for <>; Mon, 26 Aug 2013 23:18:57 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-ef-521c44cfcac3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 53.C8.22048.FC44C125; Tue, 27 Aug 2013 08:18:55 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.328.9; Tue, 27 Aug 2013 08:18:55 +0200
Message-ID: <>
Date: Tue, 27 Aug 2013 08:20:00 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Bernard Aboba <>
References: <>, <> <BLU169-W105CC7D0FA6DAF024BE05C293490@phx.gbl>
In-Reply-To: <BLU169-W105CC7D0FA6DAF024BE05C293490@phx.gbl>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje55F5kggzcLzCz2L7nMbLH85QlG i7X/2tkdmD2m3b/P5vG45wybx5IlP5kCmKO4bFJSczLLUov07RK4MuacWM5e8FmqYunuugbG g6JdjJwcEgImEnOWz2SEsMUkLtxbz9bFyMUhJHCYUWLmmVNQznJGic1tR1hBqngFtCVerd/I AmKzCKhKrJvcxQZiswlYSNz80QhmiwoES7Rv/8oGUS8ocXLmE6B6Dg4RAV2Jv11GIGFmAS+J 5zt3gC0WFrCT6Fn3kwVi12pGibWH1jKDJDgFrCXOPT/KCnGdpMS2RcfYIZr1JKZcbWGEsOUl mrfOBqsXArqtoamDdQKj0Cwkq2chaZmFpGUBI/MqRvbcxMyc9HLzTYzA8D245bfBDsZN98UO MUpzsCiJ827WOxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFHRe5QTi9XHHeWWmJWUPyP SXu9u9lia+b3HP8/edfprM332Rwucfz5tnrtnDM5tTuqG1flyXzbtThixqXqNG5epo+LWpTd Ztb+XNf1/fG2mu1xYmIuQqnrN6jFrkz14Om/0/Pq7w4Dh+1R+lb6LIlflc76rrhRZuLbF89b osqefClo5tvGG0osxRmJhlrMRcWJACKSbWctAgAA
Cc: "" <>, Colin Perkins <>
Subject: Re: [rtcweb] #25: Section 5.1 Conferencing Extensions
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, 27 Aug 2013 06:19:05 -0000

On 2013-08-26 20:00, Bernard Aboba wrote:
> Section 5.1 says: 
>    These extensions are not necessary for interoperability; an RTP endpoint
>    that does not implement these extensions will work correctly, but
>    might offer poor performance. 
>  Colin said: 
> "I suggest that TMMBR sets an envelope within which the congestion
> control should operate, but shouldn't be required for congestion control
> to work. The others might be useful in conjunction with a congestion
> control algorithm, to suggest how a new rate is to be achieved, but also
> aren't required."
> [BA] It's certainly possible to implement sender-side congestion control
> that wouldn't need TMMBR.   Also, there is the circuit breaker document.
>  However, Section 5.1.6 states the following: 
>    WebRTC senders are REQUIRED to implement support for TMMBR messages,
>    and MUST follow bandwidth limitations set by a TMMBR message received
>    for their SSRC.  The sending of TMMBR requests is OPTIONAL.
> As noted in RFC 2119 Section 6: 
>    In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
> On reading section 5.1.6, I had assumed that the TMMBR mandate derived
> from a need to ensure interoperability of a potential (receiver-side)
> congestion control mechanism.   But if that's not the case, then based
> on RFC 2119 Section 6, I don't understand why TMMBR is REQUIRED.  Also,
> doesn't TMMBR have utility beyond conferencing scenarios as stated in
> Section 5.1?  Not sure I would lump TMMBR in with FIR, PLI, SLI, etc. 

TMMBR has at least usage in two different scenarios for RTCWEB. The
first is the upstream flow control for conferences being implemented
with a central node acting as RTP mixer, and thus breaking congestion
control loops between itself and each participant, thus requiring a flow
control mechanism for a upstream media source. Implementing sender side
congestion control TMMBR is required to make the upstream flow control
function. This is documented in Section 5.1.6

The second usage is allowing proprietary receiver based congestion
control to have a method of effecting the media sender. If you don't
have receiver based congestion control, then you don't use it. But your
peer may have and send your implementation TMMBR requests. See section 7.

>From a system interoperability point of view I personally see each of
these making TMMBR required. Combining the two reasons makes it even
stronger reason to have TMMBR as required functionality. Thus I think
there are good reasons fulfilling the requirements RFC 2119 lays out to
mandate TMMBR.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: