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

[Magnus Westerlund <[e-mail]>]

Thanks Christian,

You are correct, these section references points to the wrong sections,
will address.

/Magnus

On 2014-04-07 04:42, Christian Groves wrote:
> Hello Magnus,
> 
> Please see my comments marked CNG below.
> 
> Regards, Christian
> 
> On 4/04/2014 8:24 PM, 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]).
> [CNG] Is 3.6.2 the right reference? clause 3.8 talks about
> Topo-Video-switch-MCU and the reports problem.
>>
>>     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]).
> [CNG] Is 3.8 the right reference? clause 3.9 talks about loop detection
> for Topo-RTCP-
>       terminating-MCU.
>>
>>     o  The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology
>>        SHOULD NOT be used because its safe use requires a point to
>>        multipoint congestion control algorithm or RTP circuit breaker,
>>        which has not yet been standardised.
>>
>>     The RTP extensions described in Section 5.1.1 to Section 5.1.6 are
>>     designed to be used with centralised conferencing, where an RTP
>>     middlebox (e.g., a conference bridge) receives a participant's RTP
>>     packet streams and distributes them to the other participants.  These
>>     extensions are not necessary for interoperability; an RTP end-point
>>     that does not implement these extensions will work correctly, but
>>     might offer poor performance.  Support for the listed extensions will
>>     greatly improve the quality of experience and, to provide a
>>     reasonable baseline quality, some of these extensions are mandatory
>>     to be supported by WebRTC end-points.
>>
>>     The RTCP conferencing extensions are defined in Extended RTP Profile
>>     for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
>>     AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio-
>>     Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully
>>     usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124].
>>
>>
>> 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
>>
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 


-- 

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]
----------------------------------------------------------------------