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

[Magnus Westerlund <[e-mail]>]

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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------