[rtcweb] New topic: Model for multi-unicast support

Harald Alvestrand <harald@alvestrand.no> Thu, 01 September 2011 11:56 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 991D821F8713 for <rtcweb@ietfa.amsl.com>; Thu, 1 Sep 2011 04:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.207
X-Spam-Status: No, score=-107.207 tagged_above=-999 required=5 tests=[AWL=3.392, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RxDQo57H69J1 for <rtcweb@ietfa.amsl.com>; Thu, 1 Sep 2011 04:56:28 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id C1A7A21F86EA for <rtcweb@ietf.org>; Thu, 1 Sep 2011 04:56:27 -0700 (PDT)
Received: from localhost (localhost []) by eikenes.alvestrand.no (Postfix) with ESMTP id ACACB39E175 for <rtcweb@ietf.org>; Thu, 1 Sep 2011 13:56:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([]) by localhost (eikenes.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id 82rTmgBkYV4Z for <rtcweb@ietf.org>; Thu, 1 Sep 2011 13:56:42 +0200 (CEST)
Received: from [] (unknown []) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1CEF939E173 for <rtcweb@ietf.org>; Thu, 1 Sep 2011 13:56:42 +0200 (CEST)
Message-ID: <4E5F7344.4060803@alvestrand.no>
Date: Thu, 01 Sep 2011 13:57:56 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110805 Thunderbird/3.1.12
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] New topic: Model for multi-unicast support
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 01 Sep 2011 11:56:28 -0000

In the thread about draft-perkins-rtcweb-usage, the following exchange 
took place:
>> >  Speaking for some implementors of the WEBRTC API, it's also clear that there's a significant cost to implementing the multiway RTP session concept - both in code complexity and API complexity. I think this warrants more discussion, where all 3 outcomes should be on the table:
>> >  
>> >  - We recommend doing multi-unicast with a shared RTP session only
>> >  - We recommend supporting both shared and split RTP sessions for multi-unicast
>> >  - We recommend doing multi-unicast with split RTP sessions only
>> >  
>> >  We should probably do this in a new thread.
> Indeed; I'd be interested to know what complexity you're seeing. I would have expected the shared RTP session model to decrease complexity, since the RTP layer can be oblivious to the detail of the underlying transport connections, and wouldn't have to worry about tracking SSRC and payload type mapping separately for each session.
I think this is a topic that deserves its own thread.

The context is use case 4.2.7, "Multiparty video communication", the one 
without a central server; each party sends its video and audio streams 
to all participants in the meeting directly.

One can imagine supporting this with a single RTP session, where all 
video streams are equal and sent with the same SSRC to all participants, 
all participants send receiver reports (RRs) about all the SSRCs they 
see to all other participants, and all senders send their SR reports to 
all participants.

Now, this has implications for both API design, service design and 
protocol operation.

API: The model presented is no longer "this object is your connection to 
A; that object is your connection to B". There has to be a 
representation of your "cloud" as a multidestination object, with 
procedures for adding to and subtracting from the list of participants. 
Error reporting must include which participant the error relates to.

Service: The requirement for perfect equality means that you cannot 
allow any party to adapt its presence to what it can receive; for 
instance, as I understand it, nobody can drop the video and only be an 
audio participant, because that would break the model of equality, 
rendering sender reports meaningless to some participants.

Protocol: The requirement for a single agreed RTCP bandwidth means that 
this bandwidth has to be computed for the session as a whole - with the 
simplistic answer being 5% of the lowest common denominator.

In contrast, if one chooses the multiple-RTP-session approach:

- the API retains its "one object, one destination" orientation.

- the degree to which service is equal to all parties is a matter for 
the application, not the protocol

- rate adaption, choice of RTP bandwidht and so on can be negotiated on 
each link individually

I think this forum needs to pick one of the options in my initial note, 
and design its protocols and APIs accordingly.