Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage
Harald Alvestrand <harald@alvestrand.no> Mon, 07 April 2014 08:12 UTC
Return-Path: <harald@alvestrand.no>
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 AFDC21A069C for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 01:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 pc4VdHJgubYN for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 01:12:33 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 47F4B1A017A for <rtcweb@ietf.org>; Mon, 7 Apr 2014 01:12:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 517AC7C08EA for <rtcweb@ietf.org>; Mon, 7 Apr 2014 10:12:24 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0urUprkQgp4U for <rtcweb@ietf.org>; Mon, 7 Apr 2014 10:12:14 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id B5BDE7C03E5 for <rtcweb@ietf.org>; Mon, 7 Apr 2014 10:12:14 +0200 (CEST)
Message-ID: <53425DDE.2030005@alvestrand.no>
Date: Mon, 07 Apr 2014 10:12:14 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.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
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rpymcZgM6viiq7Lwdvr5d7HbyIk
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 08:12:38 -0000
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). 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. > > 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] Draft proposal for updating Multiparty t… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Christian Groves
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Roni Even
- Re: [rtcweb] Draft proposal for updating Multipar… Roni Even
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Roni Even
- Re: [rtcweb] Draft proposal for updating Multipar… Cullen Jennings (fluffy)
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Cullen Jennings (fluffy)
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Bernard Aboba