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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 15 April 2014 15:14 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 A96EA1A0476 for <rtcweb@ietfa.amsl.com>; Tue, 15 Apr 2014 08:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 umR9VgE29KOy for <rtcweb@ietfa.amsl.com>; Tue, 15 Apr 2014 08:14:17 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0861A03E5 for <rtcweb@ietf.org>; Tue, 15 Apr 2014 08:14:16 -0700 (PDT)
X-AuditID: c1b4fb30-f791c6d000005f7c-ae-534d4cc49d8a
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.07.24444.4CC4D435; Tue, 15 Apr 2014 17:14:13 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.174.1; Tue, 15 Apr 2014 17:14:12 +0200
Message-ID: <534D4CC4.9040107@ericsson.com>
Date: Tue, 15 Apr 2014 17:14:12 +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: 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>
In-Reply-To: <5342ABBB.9050300@alvestrand.no>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvje5RH99ggynHeSyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGWcv72duWCpccXzj11sDYzTNLsYOTkkBEwk piyaxgZhi0lcuLceyObiEBI4yigxec8OVghnOaPEo4l/WEGqeAW0Jc4c/scEYrMIqEo0nf7D CGKzCVhI3PzRCDZJVCBYYumcxSwQ9YISJ2c+AbNFBOwlLs55CWYLC2RITGvaDLWtl1Hi6MXD YAs4BXQl2m69Ze5i5AA6SVyipzEIJMwsoCcx5WoLI4QtL9G8dTYziC0EdE9DUwfrBEbBWUjW zULSMgtJywJG5lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgQF7cMtvgx2ML587HmIU4GBU 4uHVPeceLMSaWFZcmXuIUZqDRUmc99tZoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGqaxc mS+C+3/3e36yPqAuWjorwvL4CqMMF3V1vcIJ+V2sixez+hYLr3pg/Hn3xqs9sb7bpyzV+jZp s/rjjl7vki6pn3NElZ6sDp1ybJ6wvib7I5GDbszbzr8/wjLXzTHvr23oPL9go4kv1savrH18 5M7ttbfey6/tzfZWMFx3tYxZ586527l6SizFGYmGWsxFxYkAr/iItDkCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PxQusli99ldZ-Nlk0OVR4o7WQGk
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, 15 Apr 2014 15:14:21 -0000

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