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

[Colin Perkins <[e-mail]>]

On 27 Aug 2013, at 12:25, Bernard Aboba <[e-mail]> wrote:
> Comments below.
> 
> On Aug 26, 2013, at 23:18, "Magnus Westerlund" <[e-mail]> 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. 
>> 
>> 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.
> 
> [BA] So why not say something along those lines? The statement in Section 5.1 doesn't seem to apply to TMMBR.

The draft does discuss both those issues, in Sections 5.1.6 and 7.1. Can you say what you think is missing from those?

-- 
Colin Perkins
http://csperkins.org/