Subject: [rtcweb] Data transfer

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 16 Sep 2011 08:32:34 +0200

A comment on the list made me go back and re-read the charter. One thing I had missed is the data transfer part of rtcweb.

"The goal is to enable innovation on
  top of a set of basic components.  One core component is to enable
  real-time media like audio and video, a second is to enable data
  transfer directly between clients."
Most of the discussions on the list has been about the media. What are the ideas for data transfer? Applications?

To me, this seems like an interesting feature. If it's a plain data transfer session, a bidirectional session, it's a way to open a session from Javascript to any server, acting as an rtcweb client, which is different from the current sandbox model. I could have missed this discussion, but if not, I think this is an interesting topic to bring up.

Another note, which I think is purely a mistake, is to forget realtime text - T.140 and just state audio and video. The T.140 users are natural early adoptor users of rtcweb.

/O

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 16 Sep 2011 09:02:32 +0200

Hi Olle,

> Most of the discussions on the list has been about the media. What are the ideas for data transfer? Applications?

Maybe I arrived a bit late to the party ;-) but so far I've seen discussions mainly around RTP (and related) media.

> Another note, which I think is purely a mistake, is to forget realtime text - T.140 and just state audio and video. The T.140 users are natural early adoptor users of rtcweb.

I can think of another use case for "data transfer": MSRP. A browser looks looks like a good place for having IM sessions over MSRP. Supporting file transfers would also be awesome, and MSRP is just a TCP pipe where data flows, so maybe this "data transfer" layer is the right place to do this?

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 15:45:38 +0200

Hi,

When it comes to the data transfer the discussion we have had back in
the beginning of the summer made it clear that there was clear interest
for an unreliable peer to peer datagram based channel.

Use cases include game data, meta information in conferencing. But it is
for whatever the the JS application have use for it.

When it comes to reliable data the result of the discussion was a bit
more unclear. Some interest existed, but no one was willing to be a
driving proponent to both propose technology and use cases.

When it comes to the unreliable data channel we are awaiting that
draft-cbran-rtcweb-data-00 is updated to try to provide something at
least worth discussing. As the WG has no consensus yet on the details
for solving this channel, any contribution is most welcome.

I agree that when it comes to T.140 it can easily be included as media
format that shall be supported. We have had several suggesting that and
no real objections. One can note that there goes 13 proposals for text
transfer to the dozen.

Maybe the simplest is to make a consensus call on this.

Cheers

Magnus

On 2011-09-16 09:02, Saúl Ibarra Corretgé wrote:
>> A comment on the list made me go back and re-read the charter. One
>> thing I had missed is the data transfer part of rtcweb.
>> 
>> "The goal is to enable innovation on top of a set of basic
>> components.  One core component is to enable real-time media like
>> audio and video, a second is to enable data transfer directly
>> between clients."
>> 
>> Most of the discussions on the list has been about the media. What
>> are the ideas for data transfer? Applications?
>> 
> 
> Maybe I arrived a bit late to the party ;-) but so far I've seen
> discussions mainly around RTP (and related) media.
> 
>> To me, this seems like an interesting feature. If it's a plain data
>> transfer session, a bidirectional session, it's a way to open a
>> session from Javascript to any server, acting as an rtcweb client,
>> which is different from the current sandbox model. I could have
>> missed this discussion, but if not, I think this is an interesting
>> topic to bring up.
>> 
>> Another note, which I think is purely a mistake, is to forget
>> realtime text - T.140 and just state audio and video. The T.140
>> users are natural early adoptor users of rtcweb.
>> 
> 
> I can think of another use case for "data transfer": MSRP. A browser
> looks looks like a good place for having IM sessions over MSRP.
> Supporting file transfers would also be awesome, and MSRP is just a
> TCP pipe where data flows, so maybe this "data transfer" layer is the
> right place to do this?
> 
> 
> Regards,
> 
> -- Saúl Ibarra Corretgé AG Projects
> 
> 
> 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 16:01:10 +0200

> ideas for data transfer? Applications?

Hi. Just my opinion:

Having WebSocket protocol I don't see the need for a separate/specific
data transfer protocol within WebRTC. WebSocket already allows
bidirectional traffic for carrying long text or binary data (I means
even GigaBytes of data).

Also, HTML5 offers some cool features for "downloading" data received
by the JavaScript code. See a demo:

  http://html5-demos.appspot.com/static/a.download.html

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 16:09:48 +0200

>   http://html5-demos.appspot.com/static/a.download.html

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.

Cheers

Magnus Westerlund

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 16:16:44 +0200

> find a reasonable solution that fulfills the requirements we should

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.

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.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 16:40:08 +0200

> long-data/documents between client and server, or

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.

> as transport, so MSRP relay servers are required when both endpoints

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.

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.

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.

3. Use TCP over UDP

Cheers

Magnus Westerlund

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 16:44:22 +0200

> 3. Use TCP over UDP

Does it mean implementing a TCP stack in JavaScript? :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 16:51:20 +0200

> Does it mean implementing a TCP stack in JavaScript? :)

No, I hope not. If this option would be chosen I think the functionality
would reside in the browser. Either to try to cross wire the OS TCP
stack so that the TCP packets (Checksum issues) are in fact sent over a
UDP socket or implement the TCP stack in the browser.

I don't want to leave the correctness of the congestion control
algorithm in the hand of the web service implementor.

All the above as individual

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 00:23:46 -0400

On 9/16/2011 10:40 AM, Magnus Westerlund wrote:
>> 2011/9/16 Magnus Westerlund<[email-masked]>:

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.

> concept. But the actual solution is still very early in the discussion.

Yes, see the congestion control discussion occurring now.

> JS, that buffer and retransmit lost data.
Yes; the VNC example above might do this.

> 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
[email-masked]

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 18 Sep 2011 21:36:32 -0700

> chat(you want reliable or you get to re-invent a reliable protocol over

Perhaps this should be added as a use-case? It has strong implications 
for the congestion control algorithm, as discussed at the interim 
telecon: you can have an arbitrarily large amount of data to send as 
fast as your pipe can carry it, and that has to compete with the media 
traffic.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Sep 2011 07:00:07 +0000

> appear there's an extant open-source example, so it's a hard sell.

I think you'll want to do whatever-shim-transport-it-is in the browser rather than in JS no matter what.  As much as I hate to say it, SCTP over UDP kinda makes sense, given all of it's various modes of operation.  

Whatever gets picked, it needs to support fragmentation at a layer above UDP to make it through various NATs/firewalls/CGNs. 

-hadriel
p.s. why do you say there's no open-source of SCTP?  FreeBSD has it, though it might be out of date;  sctplib is also under LGPL (http://www.sctp.de/sctp-download.html).

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Sep 2011 09:31:04 +0200

> fast as your pipe can carry it, and that has to compete with the media 
Last round, PseudoTCP over UDP (or UDP/DTLS) seemed to be the favourite 
protocol for reliable data delivery.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 03:31:32 -0400

> p.s. why do you say there's no open-source of SCTP?  FreeBSD has it, though it might be out of date;  sctplib is also under LGPL (http://www.sctp.de/sctp-download.html).
I meant SCTP-over-UDP, not direct SCTP.  (Yes, I assume a working SCTP can
be transformed into SCTP-over-UDP, but without spending some time it's hard
for me to say what level of work this would involve and the amount of testing
needed.

I'm now tempted to add *another* item to my plate...  (I need a helper just
to carry it...)  :-)

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Wed, 21 Sep 2011 08:50:00 -0700

[ Old response that was sitting on my laptop in drafts...  Feel free to 
ignore]

On 9/15/2011 11:32 PM, Olle E. Johansson wrote:
> Most of the discussions on the list has been about the media. What are 
> the ideas for data transfer? Applications?

See the Use Case document: some obvious ones are games, 
remote-assistance, web conference with screen sharing or whiteboards, 
file transfer while talking, etc.  Unreliable data channels will be 
included, and while there isn't express consensus yet I very much want 
(and think we'll have) reliable data channels, probably based on 
TCP-over-UDP (over DTLS).

> which is different from the current sandbox model. I could have missed 
> this discussion, but if not, I think this is an interesting topic to 
> bring up.

It is a way to open channels to another machine, though in response to a 
user request to do so (which is the domain of the security arena 
here).   Note that the audio and video channels are "data" channels as 
well, though perhaps the JS would be kept from direct access to the 
sources, and thus limit them as channels for exporting data from JS.

Note that if we allow webrtc clients to *send* "early" data OR early 
media in response to an OFFER, it is a potential information leak and 
security risk to evaluate.  For example, if the JS app is gathering 
typing data from an information compromise (real case, won't go into 
details), it could feed it out in realtime using "early data" in 
response to an OFFER that's never communicated to the user.  Now, this 
may not be a valid concern since I think there are plenty of other ways 
for an malevolent app to export data once it has it - just trying to 
make sure we've considered the leak and decided it's safe, IF we want to 
support sending early media/data.

-- 
Randell Jesup
[email-masked]