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

Christian Groves <Christian.Groves@nteczone.com> Mon, 07 April 2014 02:42 UTC

Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7EF1A0658 for <rtcweb@ietfa.amsl.com>; Sun, 6 Apr 2014 19:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTSAnRTscUp7 for <rtcweb@ietfa.amsl.com>; Sun, 6 Apr 2014 19:42:25 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D5C1A065D for <rtcweb@ietf.org>; Sun, 6 Apr 2014 19:42:24 -0700 (PDT)
Received: from ppp118-209-187-61.lns20.mel6.internode.on.net ([118.209.187.61]:63578 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Christian.Groves@nteczone.com>) id 1WWzVm-0002ks-9i for rtcweb@ietf.org; Mon, 07 Apr 2014 12:42:14 +1000
Message-ID: <53421089.3050506@nteczone.com>
Date: Mon, 07 Apr 2014 12:42:17 +1000
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <533E7A50.5040909@ericsson.com>
In-Reply-To: <533E7A50.5040909@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QvDv-woroT3KvylfKLJAtYw2x98
Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Apr 2014 02:42:29 -0000

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  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>