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

Bernard Aboba <> Mon, 26 August 2013 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6901811E81BC for <>; Mon, 26 Aug 2013 11:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.565
X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oiXldvoDE6AD for <>; Mon, 26 Aug 2013 11:00:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 83EFB11E81A7 for <>; Mon, 26 Aug 2013 11:00:13 -0700 (PDT)
Received: from BLU169-W105 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Aug 2013 11:00:12 -0700
X-TMN: [sejwwibAilIOrM1oWN6239U2uj/Gb9IA]
X-Originating-Email: []
Message-ID: <BLU169-W105CC7D0FA6DAF024BE05C293490@phx.gbl>
Content-Type: multipart/alternative; boundary="_34113899-7c7d-4224-86ea-a21703844933_"
From: Bernard Aboba <>
To: Colin Perkins <>
Date: Mon, 26 Aug 2013 11:00:11 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Aug 2013 18:00:12.0104 (UTC) FILETIME=[1C18FC80:01CEA286]
Cc: "" <>
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: Mon, 26 Aug 2013 18:00:26 -0000

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

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.