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

[Christopher Blizzard <[e-mail]>]

On 6/27/2011 12:36 AM, Magnus Westerlund wrote:
> WG,
>
> At the interim it was planned to have a bit discussion on the datagram
> service for RTCWEB. The first question to try to resolve if there
> is consensus for including some form of non real-time media (i.e. not
> audio, video) service between peers. This is a bit tangled with the
> actual requirements and use cases. But there was views both for it and
> against it on the mailing list. So lets continue and try to come to a
> conclusion on this discussion.
>
> The use cases mentioned on the mailing list are:
>
> - Dynamic meta data for Conference and other real-time services
>
> - Gaming data with low latency requirements
>
> Does anyone like to add additional use cases?

For web browsers we'd (Mozilla) like to see it as a more generic 
transport service for applications.  As part of our web-as-applications 
work we'd like to break some of the assumptions about how applications 
are built.  In particular, having standalone apps that are downloaded 
and installed, but built on web technologies where clients can connect 
with each other is something that's interesting.  (HTTP and WebSockets 
both require connecting via a server intermediary.)  If we had a peer to 
peer connection service, with or without video services, we would be 
able to connect applications together without servers involved, aside 
from initial set-up.  Bringing back the end to end principle actually 
matters for our apps strategy.

And yes, this is different than what other people are doing.  But it's 
one of the reasons why I've been insistent on data transmission as part 
of the peer to peer APIs and protocols.

So if I put my use case down it would be:

- Baselevel communications protocol for application to application 
communication in browsers.

And yes, that's vague.  I could use better words there.

>
> Based on my personal understanding this points to primarily have the
> RTCWEB provide a unreliable datagram service. This clearly needs
> additional requirements to be secure and safe to deploy, but more about
> this below. I still like to ask the WG here a question.
>
> Are you supporting the inclusion of a unreliable datagram service
> directly between peers? Please provide your view and any additional
> statements of motivation that you desire to provide.
>
> Secondly, there is a question if there needs to have something that
> provides reliable message (of arbitrary size) or byte stream oriented
> data transport between the peers. I personally foresee that people will
> build JS libraries for this on top of a unreliable datagram service. If
> you desire reliable data service as part of the standardized solution
> please provide motivation and use case and requirements.

I think that for the app to app case I have to imagine that the most 
common use case will be reliable transport with both messages and 
entities being sent back and forth.

But the file transfer use case, as well as trying to provide some level 
of congestion control around audio & video sessions would seem to 
indicate that we might want to have both, tbh.

But I haven't thought deeply on this particular aspect of the 
discussion.  So I'm easily swayed.

--Chris