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

[Randell Jesup <[e-mail]>]

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

>
> * active speaker indications
>
> * real-time text (along the lines of 
> http://datatracker.ietf.org/doc/rfc5194/)
>
> * 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
[e-mail]