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

["Roni Even" <[e-mail]>]

Hi,
Inline
Roni

> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Magnus
> Westerlund
> Sent: 07 April, 2014 2:15 PM
> To: Harald Alvestrand; [e-mail]
> Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in
draft-
> ietf-rtcweb-rtp-usage
> 
> 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.
> 
[Roni Even] In this topology the source identification is done by the
application layer and not the RTP layer (using for example conference event
package or just the UI). So I think that "MAY" is strong enough and not
"SHOULD NOT". I agree with Harald that it is widely used.

> >
> > 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb