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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 07 April 2014 11:16 UTC

Return-Path: <magnus.westerlund@ericsson.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 1BFA01A03CB for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 04:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 xTD60BDg12bK for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 04:16:42 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F19741A03A2 for <rtcweb@ietf.org>; Mon, 7 Apr 2014 04:16:41 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f328e0000012ab-13-53428913093e
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 67.BC.04779.31982435; Mon, 7 Apr 2014 13:16:35 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.174.1; Mon, 7 Apr 2014 13:16:35 +0200
Message-ID: <53428913.10808@ericsson.com>
Date: Mon, 7 Apr 2014 13:16:35 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@nteczone.com>, <rtcweb@ietf.org>
References: <533E7A50.5040909@ericsson.com> <53421089.3050506@nteczone.com>
In-Reply-To: <53421089.3050506@nteczone.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3Rle40ynY4PpdK4sv7xtZLNb+a2d3 YPJYsuQnk8eK8zNZApiiuGxSUnMyy1KL9O0SuDJ2rpjAWrDEuOLx3DNsDYw3NLoYOTgkBEwk Pk206GLkBDLFJC7cW8/WxcjFISRwmFFibccPRpCEkMAyRoml5z1AbF4BTYlNkzeBxVkEVCTu rn7IDGKzCVhI3PzRyAZiiwoESyyds5gFol5Q4uTMJ2C2iIC7xP27b8FqhAUyJKY1bWaDmO8t sXHvbhaQezgFdCT274+DOE1coqcxCKSCWUBPYsrVFkYIW16ieetsZohObYmGpg7WCYyCs5As m4WkZRaSlgWMzKsY2XMTM3PSyw03MQKD8eCW37o7GE+dEznEKM3BoiTO++Gtc5CQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGRvueExz31otYO82srF+tc/1T8kpZMS/jr/FpAU8lxRPe2TgJ eWmuFbB4nmis2LM0lEeJTzt2tsvH9w2Xvf9u2pCwnmXxez2HR3YzQ9e9slJxZXzR/a8mf86P 99/XO31flFPadFHqrX58H0/LRraX0qcfHTVmlooLtvkXxMa63P1euvuzqoe8SizFGYmGWsxF xYkAWAxx5xQCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4IT_ouyY6ZVR-qbYB3UEvwtk6Ag
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 11:16:47 -0000

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  +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
>>
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 


-- 

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