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