Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage

[Magnus Westerlund <[e-mail]>]

On 2014-04-07 10:12, Harald Alvestrand wrote:
> Thanks for the update!
> 
> It does seem reasonably clear now - clear enough that I found one point
> that I violently disagree with (if I'm interpreting it correctly). See
> below.
> 
> I don't have any negative comments on the rest of the section.
> 
> On 04/04/2014 11:24 AM, Magnus Westerlund wrote:
>> WG,
>> (As Author)
>>
>> Colin and I have been working on resolving terminology usage and in
>> general giving the draft a polish over before the WG last call. One
>> section that has gotten quite some attention from us is the below one.
>> The changes are significantly from an editorial stand point. However,
>> the intended content has not been intended to be changed, although
>> clarified and better motivated. So please review it, we intended to
>> include this in the upcoming draft update. Feedback appreciated.
>>
>> 5.1.  Conferencing Extensions and Topologies
>>
>>     RTP is a protocol that inherently supports group communication.
>>     Groups can be implemented by having each endpoint sending its RTP
>>     packet streams to an RTP middlebox that redistributes the traffic, by
>>     using a mesh of unicast RTP packet streams between endpoints, or by
>>     using an IP multicast group to distribute the RTP packet streams.
>>     These topologies can be implemented in a number of ways as discussed
>>     in [I-D.ietf-avtcore-rtp-topologies-update].
>>
>>     While the use of IP multicast groups is popular in IPTV systems, the
>>     topologies based on RTP middleboxes are dominant in interactive video
>>     conferencing environments.  Topologies based on a mesh of unicast
>>     transport-layer flows to create a common RTP session have not seen
>>     widespread deployment.  Accordingly, WebRTC implementations are not
>>     expected to support topologies based on IP multicast groups.  WebRTC
>>     implementations are also not expected to support mesh-based
>>     topologies, such as a point-to-multipoint mesh configured as a single
>>     RTP session (Topo-Mesh in the terminology of
>>     [I-D.ietf-avtcore-rtp-topologies-update]).  However, a point-to-
>>     multipoint mesh constructed using several RTP sessions, in the WebRTC
>>     context using independent RTCPeerConnections can be expected to be
>>     utilised by WebRTC applications.
>>
>>     WebRTC implementations of RTP endpoints implemented according to this
>>     memo are expected to support all the topologies described in
>>     [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send
>>     and receive unicast RTP packet streams to some peer device, provided
>>     that peer can participate in performing congestion control on the RTP
>>     packet streams.  The peer device could be another RTP endpoint, or it
>>     could be an RTP middlebox that redistributes the RTP packet streams
>>     to other RTP endpoints.  This limitation means that some of the RTP
>>     middlebox-based topologies are not suitable for use in the WebRTC
>>     environment.  Specifically:
>>
>>     o  Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used,
>>        since they make the use of RTCP for congestion control and quality
>>        of service reports problematic (see Section 3.6.2 of
>>        [I-D.ietf-avtcore-rtp-topologies-update]).
>>
>>     o  Content modifying MCUs with RTCP termination (Topo-RTCP-
>>        terminating-MCU) SHOULD NOT be used since they break RTP loop
>>        detection, and prevent receivers from identifying active senders
>>        (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]).
> 
> In my (strong) opinion: This recommendation is wrong.
> 
> All central conferencing units that use individual RTP sessions with
> clients fall into this category. This includes, I believe, every single
> multiuser video conferencing system based on WebRTC in existence (and
> there are many of them).

Do they? The point of this topology is that it terminates the source
identification and hides when it is performing any type of mixing or
switching operation. You can perform this with a back to back RTP
session style without breaking this property. Just by correctly linking
information between the sessions. Which means that the individual RTP
session is from the identification part inseparable from an SFM or
classic RTP mixer. Only the SSRC level loop detection gets impacted.

I do understand that people have implemented it this way. Implementation
are not necessarily equivalent to recommended practice.

> 
> I believe the recommendation should be:
> 
> * Content modifying MCUs with RTCP termination
> (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, RTP
> loop detection and identification of active senders is the resposibility
> of the application; since the clients are isolated from each other at
> the RTP layer, RTP cannot assist with these functions.
> 

If this topology was without issues, then one would simply remove the
bullet, and let it fall under the general clause. However, it clearly
needs that warning. Which results in this topology being both positively
and negatively treated in regards to the other "you may encounter this
topology".

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------