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

From: "rtcweb issue tracker" <[email-masked]>
Date: Sun, 25 Aug 2013 22:54:00 -0000

#25: Section 5.1 Conferencing Extensions

 These
    central servers can be implemented in a number of ways as discussed
    in Appendix A, and in the memo on RTP Topologies
    [I-D.westerlund-avtcore-rtp-topologies-update].

 [BA] Out-of-date reference; should be to draft-ietf-avtcore-rtp-
 topologies-update.

    o  The use of video switching MCUs makes the use of RTCP for
       congestion control and quality of service reports problematic(see
       Section 3.7 of [I-D.westerlund-avtcore-rtp-topologies-update]).

 [BA] In the new document, this is now Section 3.6.2.

    o  RTP Transport Translators (Topo-Translator) are not of immediate
       interest to WebRTC, although the main difference compared topoint
       to point is the possibility of seeing multiple different
       transport paths in any RTCP feedback.

 [BA] "not of immediate interest" might be interpreted as not satisfying
 the requirement that "these topologies require no special RTP-layer
 support in the end-point if the RTP features mandated in this memo are
 implemented". If a browser can handle an undeclared SSRC then wouldn't an
 RTP translator also satisfy the requirement?  For example, Section 11
 states: "The API also needs to be capable of handling when new SSRCs are
 received but not previously signalled by signalling in some fashion."

    These
    extensions are not necessary for interoperability; an RTP endpoint
    that does not implement these extensions will work correctly, but
    might offer poor performance.

 [BA] I'd argue that not implementing the extensions will also affect
 aspects such as congestion control, which one might argue is necessary to
 "work correctly".

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-rtcweb-rtp-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  rtp-usage                |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/rtcweb/trac/ticket/25>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 26 Aug 2013 16:30:50 +0100

> [BA] Out-of-date reference; should be to draft-ietf-avtcore-rtp-

Will fix.

> [BA] In the new document, this is now Section 3.6.2.

Will fix.

> [BA] "not of immediate interest" might be interpreted as not satisfying the requirement that "these topologies require no special RTP-layer support in the end-point if the RTP features mandated in this memo are implemented". If a browser can handle an undeclared SSRC then wouldn't an RTP translator also satisfy the requirement?  For example, Section 11 states: "The API also needs to be capable of handling when new SSRCs are received but not previously signalled by signalling in some fashion."

I see no reason why a transport translator couldn't be used in the WebRTC context, so I propose to remove this bullet.

> [BA] I'd argue that not implementing the extensions will also affect aspects such as congestion control, which one might argue is necessary to "work correctly".

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.

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Aug 2013 11:00:11 -0700

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Aug 2013 08:20:00 +0200

On 2013-08-26 20:00, Bernard Aboba wrote:
> "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: 
> 
> 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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Aug 2013 04:25:10 -0700

Comments below.

> there are good reasons fulfilling the requirements RFC 2119 lays out to

[BA] So why not say something along those lines? The statement in Section 5.1 doesn't seem to apply to TMMBR.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Aug 2013 22:36:02 +0100

On 27 Aug 2013, at 12:25, Bernard Aboba <[email-masked]> wrote:
>> 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.
> 

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/

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Aug 2013 18:24:17 -0700

Colin said: 

"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?"

[BA] My issue wasn't really with Sections 5.1.6 and 7.1 (or with the TMMBR mandate).  It was with the text in Section 5.1, which seems to contradict the reasoning for mandating TMMBR.  As Magnus noted, TMMBR needs to be implemented to support congestion and flow control, which makes it more than just a performance concern.  That puts it in a different category from FIR, for example.