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

[Bernard Aboba <[e-mail]>]

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.