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

Harald Alvestrand <harald@alvestrand.no> Tue, 15 April 2014 21:57 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 8D6841A074F for <rtcweb@ietfa.amsl.com>; Tue, 15 Apr 2014 14:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 vgM35NJo8W2u for <rtcweb@ietfa.amsl.com>; Tue, 15 Apr 2014 14:57:16 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id D13F91A07A0 for <rtcweb@ietf.org>; Tue, 15 Apr 2014 14:57:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 568D57C52BD; Tue, 15 Apr 2014 23:57:12 +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 BPdPWASh4X+l; Tue, 15 Apr 2014 23:57:11 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:58bb:20e7:5cb8:4b63] (unknown [IPv6:2001:470:de0a:27:58bb:20e7:5cb8:4b63]) by mork.alvestrand.no (Postfix) with ESMTPSA id EF5CD7C52A6; Tue, 15 Apr 2014 23:57:10 +0200 (CEST)
Message-ID: <534DAB36.3070105@alvestrand.no>
Date: Tue, 15 Apr 2014 23:57:10 +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> <5342ABBB.9050300@alvestrand.no> <534D4CC4.9040107@ericsson.com>
In-Reply-To: <534D4CC4.9040107@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/5EkpaoIzI80Y6tGwfTkxpVzlpYo
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 21:57:24 -0000

On 04/15/2014 05:14 PM, Magnus Westerlund wrote:
> 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.

Grammar warning: The above can be parsed as either

(multipoint congestion control algorithm) or (RTP circuit breaker)

or

multipoint ((congestion control algorithm) or (RTP circuit breaker))

Only the second parse will be a true statement once -circuit-breaker
(a normative dependency) is published. Perhaps this needs rephrasing?

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

This text looks reasonable to me.

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