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

"Roni Even" <ron.even.tlv@gmail.com> Sun, 20 April 2014 15:39 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 80BEF1A000A for <rtcweb@ietfa.amsl.com>; Sun, 20 Apr 2014 08:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 WOmbG8Lz7b71 for <rtcweb@ietfa.amsl.com>; Sun, 20 Apr 2014 08:38:57 -0700 (PDT)
Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id D6C7A1A0008 for <rtcweb@ietf.org>; Sun, 20 Apr 2014 08:38:56 -0700 (PDT)
Received: by mail-ee0-f49.google.com with SMTP id c41so3046053eek.36 for <rtcweb@ietf.org>; Sun, 20 Apr 2014 08:38:51 -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=SiIU7XoDdXrRIpYTLysUY2oN+S4e1RrZJZc69I5QKKM=; b=nqGtvdwjSSOq2XChreDWithlz3FkVReLgdiacBRpnr4ocC9e2ExFV+bmuA/V2nH56N 1d9w7y2rl5A9Mfdv2xaeId7WjHMt0q8IaQf/wFE21mXn7eHmdOSpwRWM8OGG2CO6brHB bZHf4C98y8Qe09ujGGJV+w1gBTqK570A9/OfeuaWGqCY7Rk6T6ghCsh1qs2tHgL1upJL hKl9d7ChyRVjuJwo1kmlQPsGwPHacRyvN95gQAXJwRC0nfIIqT64OQt8YKQy4Fpm533P 9V6BHEsXVdD+2Qs8tmYidlXHhXbJRLNh4Ssn/d4416140f+EkLmKj/tv+fLrXX4PYU/k vNeQ==
X-Received: by 10.14.206.137 with SMTP id l9mr39691222eeo.40.1398008331695; Sun, 20 Apr 2014 08:38:51 -0700 (PDT)
Received: from RoniE ([109.67.104.144]) by mx.google.com with ESMTPSA id x45sm95512772eef.15.2014.04.20.08.38.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 20 Apr 2014 08:38:50 -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> <5342ABBB.9050300@alvestrand.no> <534D4CC4.9040107@ericsson.com>
In-Reply-To: <534D4CC4.9040107@ericsson.com>
Date: Sun, 20 Apr 2014 18:38:46 +0300
Message-ID: <021801cf5cae$9fe25970$dfa70c50$@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+W4VAKvzAr7AQtGn5wBZ5knWQIJh4ZSmX8PMXA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cz9Q77wgDrkvWvJKCWm-r_CSE1o
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: Sun, 20 Apr 2014 15:39:01 -0000

Hi Magnus,
I am OK with the text.
Do you think that for Multiparty we should state that a mixed conference
(WebRTC and non WebRTC participants) is possible and should also support
these rules.
 
Roni 


> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus
> Westerlund
> Sent: 15 April, 2014 6:14 PM
> To: Harald Alvestrand; rtcweb@ietf.org
> Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in
draft-
> ietf-rtcweb-rtp-usage
> 
> Hi,
> 
> I have considered these comments and are okay with modifying the
> recommendation. I have modified the proposed text from Harald somewhat.
> My proposal is the following:
> 
> 
>    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 and from 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.8 of
>       [I-D.ietf-avtcore-rtp-topologies-update]).
> 
>    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 following topology may be used, however it has considerations
>    worth noting:
> 
>    o  Content modifying MCUs with RTCP termination (Topo-RTCP-
>       terminating-MCU) MAY be used.  Note that in this RTP Topology, RTP
>       loop detection and identification of active senders is the
>       responsibility of the WebRTC application; since the clients are
>       isolated from each other at the RTP layer, RTP cannot assist with
>       these functions (see section 3.9 of
>       [I-D.ietf-avtcore-rtp-topologies-update]).
> 
> 
> Please provide feedback on this text!
> 
> Please see further response to questions and comments inline below.
> 
> 
> On 2014-04-07 15:44, Harald Alvestrand wrote:
> > On 04/07/2014 01:15 PM, Magnus Westerlund wrote:
> >> On 2014-04-07 10:12, Harald Alvestrand wrote:
> 
> >>> 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.
> 
> The correctly linking information is mostly a question of preserving
CNAMEs
> across the middlebox to ensure that an end-point can determine
> synchronization contexts, and origin if CSRC are used. As we add
additional
> meta data about streams they may also needs to preserved depending on
> scope. Here it becomes a question of how one deals with APPID and MSID.
> 
> Preserving SSRC is a choice, if one does it then loop detection works, if
one
> doesn't preserve it it doesn't. Preserving it avoids having to remap any
> information that have global scope across the legs.
> 
> It becomes a choice on what complexities one needs to handle, common
> uniqueness requirements versus remapping I think is the major trade-off.
> 
> >
> >>   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.
> 
> You are welcome to propose changes regarding this to the topologies-update
> document in AVTCORE WG.
> 
> >>
> >>> 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.
> 
> Yes, I agree that in a basic conference application with only a single
server
> instance this is unlikely to form a loop. If one starts doing more complex
things,
> including multi-server conferences or PeerConnection Meshes things become
> more complex. The later we anyway have removed the RTP loop detection due
> to the CNAME being unique on PeerConnection level, but I do think that is
the
> right trade-off from privacy point of view.
> 
> >
> > Anyway, I stand by my statement: SHOULD NOT is the wrong thing to say.
> 
> I do accept this, and are willing to change the recommendation.
> 
> 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