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

"Roni Even" <ron.even.tlv@gmail.com> Tue, 08 April 2014 15:04 UTC

Return-Path: <ron.even.tlv@gmail.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 56C401A03DF for <rtcweb@ietfa.amsl.com>; Tue, 8 Apr 2014 08:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 YGhAkJ56s0_w for <rtcweb@ietfa.amsl.com>; Tue, 8 Apr 2014 08:04:55 -0700 (PDT)
Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D5FA81A03BA for <rtcweb@ietf.org>; Tue, 8 Apr 2014 08:04:54 -0700 (PDT)
Received: by mail-ee0-f45.google.com with SMTP id d17so807225eek.4 for <rtcweb@ietf.org>; Tue, 08 Apr 2014 08:04:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=ptKgY4+P+5j3pNrhEht3iGMz+dOsVXQJnxRME3kSaLE=; b=m3BvFvHdCFoKTfoL3H0fx9sJeiNAts0xuWDlzdBA0Clp9D8XAh8VS0twQAr6Amiyuf /Od4HlI+FJsWiOui4KQUFJnCufNCENuPk1MrNXtbCwSTf6VhApPKx5ql6MzXoNDRGrFM 3FwzdHvI9KMjmMLeoGxNOmv51gmB0taAFewC7xVc9r8DV4M4xTboKrny8u/ZfFs3nxcs WfhLkh+2BPFk9nC79Vpcu2iJh5kzGBfkt3Oeyr2yVcs4OORedXQ2wbJasvf1WGoEOCUX 1Q9eX0GVp/vTvcUKsnbybcPwKT5c5FR0emLd1TB2Dopz4dIgRl+iDAJZ5gF8Ps8Ktn1S l2Nw==
X-Received: by 10.15.10.135 with SMTP id g7mr3358228eet.72.1396969494330; Tue, 08 Apr 2014 08:04:54 -0700 (PDT)
Received: from RoniE (bzq-79-183-174-212.red.bezeqint.net. [79.183.174.212]) by mx.google.com with ESMTPSA id u46sm5162990eel.1.2014.04.08.08.04.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Apr 2014 08:04:53 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>, "'Harald Alvestrand'" <harald@alvestrand.no>, <rtcweb@ietf.org>
References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com>
In-Reply-To: <534288C2.6010906@ericsson.com>
Date: Tue, 8 Apr 2014 18:04:50 +0300
Message-ID: <010301cf533b$e504d9f0$af0e8dd0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKAdRtyny0O/9Ki8/9GVI+Yi+W4VAKvzAr7AQtGn5yZh7O9sA==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h1qVglzhqlXPjDGXxUDVAqmuroU
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: Tue, 08 Apr 2014 15:04:59 -0000

Hi,
Inline
Roni

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus
> Westerlund
> Sent: 07 April, 2014 2:15 PM
> To: Harald Alvestrand; rtcweb@ietf.org
> Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in
draft-
> ietf-rtcweb-rtp-usage
> 
> 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. 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.
> 
[Roni Even] In this topology the source identification is done by the
application layer and not the RTP layer (using for example conference event
package or just the UI). So I think that "MAY" is strong enough and not
"SHOULD NOT". I agree with Harald that it is widely used.

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