Re: [rtcweb] Data transfer

[Randell Jesup <[e-mail]>]

On 9/16/2011 10:40 AM, Magnus Westerlund wrote:
> On 2011-09-16 16:16, Iñaki Baz Castillo wrote:
>> 2011/9/16 Magnus Westerlund<[e-mail]>:
>>> The argument for having a peer to peer unreliable datagram channel has
>>> been two:
>>>
>>> 1) Minimal delay by direct peer-to-peer connection instead of going
>>> through a central server. This as you can't normally establish a
>>> websocket connection to a browser behind a NAT/FW.
>>>
>>> 2) Scalability by not requiring a server or having to handle the data
>>> flows at all on the server side.
>>>
>>> As an individual I think these arguments are good, and assuming we can
>>> find a reasonable solution that fulfills the requirements we should
>>> specify it.
>> I'm not opposed to such mechanism if approved. But given the current
>> WWW reality, web applications always use HTTP for carrying
>> long-data/documents between client and server, or
>> client-server-client.
> As I said in another email in this thread the WG have had discussion of
> also peer to peer reliable data transport that are capable of handling
> larger data object transfers between the peers. However, the discussion
> didn't result in a clear consensus for this case. Nor a proponent
> surfaced that has continued driving the case.

I'm a strong proponent of a reliable channel as are the other Mozilla folk,
and thought that several of our existing use-cases covered this.  For
example a two (or multi) player game - games frequently use both unreliable
channels (to avoid freezing the game if certain non-critical updates are
lost) and reliable data ("you're dead", etc).  This has been the case since
the earliest days of real-time games on the internet (before the web
existed; see the 'netrek' game/protocol for example).

There are many other uses of peer-to-peer data, such as file-transfer during
chat(you want reliable or you get to re-invent a reliable protocol over UDP),
VNC-like screen updates (probably unreliable with a recovery mechanism),
mouse/keyboard events when doing remote assistance (reliable), etc.  There are
some interesting peer-to-peer mesh protocols which would benefit from reliable
data that might be possible to layer on top of webrtc; we'll likely be
investigating this at mozilla.

You also don't want websockets for data channels here; you want it tied to
the webrtc session and you don't want the overhead/cost/delay of having to
do a separate relay.


>> Also I don't think that data transfer can be achieved using an
>> unreliable data channel (so UDP), is it? For example in SIP protocol
>> MSRP has emerged for this purpose (data transfer) and it uses TCP/TLS
>> as transport, so MSRP relay servers are required when both endpoints
>> are behind NAT.
> I think we all agree that for NAT traversal we are expecting it to be
> IP/UDP/FOO. And it is most likely IP/UDP/DTLS/FOO to have confidential,
> source authenticated and integrity protected transfers. Where FOO
> provides congestion control and possible some type of framing or stream
> concept. But the actual solution is still very early in the discussion.

Yes, see the congestion control discussion occurring now.

> When it comes to data transfer, of course you can achieve reliable
> transport over an UDP. I think I can mention several different methods
> in how to achieve it.
>
> 1. In this context one option is to implement a reliability function in
> JS, that buffer and retransmit lost data.
Yes; the VNC example above might do this.

> 2. Another one would be to use NORM (RFC5740) as the transport protocol
> inside DTLS. NORM provides both congestion control and reliability. Yes,
> it might have a few over designed features being intended for multicast.

Interesting; I'll take a look.  Thanks.


> 3. Use TCP over UDP
This is what I had been assuming we'd do.  It might have been nice to use
SCTP-over-UDP instead; that would cover more cases without having to drop
into doing network protocols in javascript for example, but it doesn't
appear there's an extant open-source example, so it's a hard sell.


-- 
Randell Jesup
[e-mail]