Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage
Harald Alvestrand <harald@alvestrand.no> Mon, 07 April 2014 13:45 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 AC16A1A0429 for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 06:45:04 -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 2crImysKsf12 for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 06:44:55 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE7F1A0708 for <rtcweb@ietf.org>; Mon, 7 Apr 2014 06:44:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 19DA47C50D4; Mon, 7 Apr 2014 15:44:31 +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 HIZ-Fsgb2IAJ; Mon, 7 Apr 2014 15:44:30 +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 D423A7C50C7; Mon, 7 Apr 2014 15:44:29 +0200 (CEST)
Message-ID: <5342ABBB.9050300@alvestrand.no>
Date: Mon, 07 Apr 2014 15:44:27 +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: Magnus Westerlund <magnus.westerlund@ericsson.com>, rtcweb@ietf.org
References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com>
In-Reply-To: <534288C2.6010906@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/c5MVIwXou0G_2Nnlr7aIljCU6PE
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 13:45:05 -0000
On 04/07/2014 01:15 PM, Magnus Westerlund wrote: > 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. Is there a definition for "correctly linking information"? In particular, are you thinking of mappings that preserve SSRC? Because that's not the ones I'm thinking of. > 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. But when there's one common practice, and no recommended practice, that might be a gentle hint that there's a reason why people are doing it - indeed, it might be worth making it a recommended practice. > >> 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". It might need that warning - I'm not sure it's a real issue; loop detection is only an issue when you have potential loops, and in a single-mixer architecture, that potential is minimal (each endpoint knows perfectly well the difference between what it's sourcing and what it's receiving). Identification of active senders can be an application-layer thing. Anyway, I stand by my statement: SHOULD NOT is the wrong thing to say. > > 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] 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