Re: [rtcweb] Non-media data service consensus and requirements

Randell Jesup <> Wed, 29 June 2011 04:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F30D21F8527 for <>; Tue, 28 Jun 2011 21:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IM1WoMNdsGcF for <>; Tue, 28 Jun 2011 21:15:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4574321F84DA for <>; Tue, 28 Jun 2011 21:15:13 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1QbmBD-0001LI-Q2 for; Tue, 28 Jun 2011 23:15:11 -0500
Message-ID: <>
Date: Wed, 29 Jun 2011 00:12:19 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Non-media data service consensus and requirements
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jun 2011 04:15:14 -0000

On 6/28/2011 3:45 PM, Jonathan Rosenberg wrote:
> Here are some thoughts on additional use cases:
> * information on congestion and receiver side environment for purposes 
> of improved sender rate adaptation

Aka active bandwidth adaptation.  This will generally be better over 
RTCP or other unreliable-but-low-latency channel.

One thing we may want to address is handling congestion across a set of 
streams, instead of only a single stream.  Current mechanisms are 
stream-oriented, which both can cause unexpected conflicts between 
related streams (audio and video for example), and also allows 
"cheating" congestion rules by opening multiple 'connections' (streams).

This was one thing that RTMFP got right, along with allowing reliable 
datagram services.  As mentioned, if it's not provided then N*M people 
will try to implement reliable transport over whatever streams we give 
them (including random RTP streams), and as someone said, they'll make 

> * active speaker indications
> * real-time text (along the lines of 
> * video controls - application driven intra-frame requests, for example

I suspect these should be dealt with using normal rtcpfb mechanisms, 
there there may be needs for a reliable transport of this request.

> * floor control requests/grants

And as was mentioned user input events in a VNC/RDP-type remote 
browser-sharing.  (and yes, there are security issues here!)  These are 
both latency-sensitive and must be reliable (or at least a subset of 
events must be reliable, and probably all do).

> All of these share the common property of being latency sensitive, and 
> thus more appropraite for p2p vs. server mediated. The other driver 
> for p2p data transport is cost reduction, to avoid the need for server 
> mediation for transfer of data. File transfer is the main example of 
> this.
> I view the latency-sensitive use cases as a higher priority for us and 
> a better match to the work we're doing here.

To be clear: I'm in favor of considering non-media unreliable and 
reliable transports.

Randell Jesup