[rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

[Magnus Westerlund <[e-mail]>]

On 2011-09-17 19:27, Hadriel Kaplan wrote:
> 
> On Sep 17, 2011, at 4:27 AM, Olle E. Johansson wrote:
> 
>> They will be able to use the rtcweb data channel, which is a
>> concern.
> 
> Yes, that's actually the most interesting piece of this whole thing,
> in my opinion.  Browsers don't typically offer raw sockets to
> javascript as far as I know.  And not only does it raise a lovely set
> of security concerns, but also network collapse issues since UDP has
> no congestion backoff and I believe the data channel we're talking
> about is UDP(?).

Well, it is something over UDP. We clearly need UDP for NAT traversal
considerations. However, we also clearly need congestion control
implemented in the browser, not in the JS to prevent two targets to
unfairly saturate the path between the peers.

> 
> And since the data channel is actually peer-to-peer rather than
> client-to-server, the issues with not standardizing its protocol
> become harder. I.e., leaving it a raw socket will only work if it
> goes between the same javascripts, inside the same domain - if that's
> ok, then the only issue is this would be put into SDP, and SDP isn't
> constrained by a javascript domain.  Hmm... gosh, if only rtcweb
> didn't use SDP as its browser API... :)

We need to standardize a number of Transport protocol functionalities
for the RTCWEB data transport solution. To the degree that I do like to
resurface some of my earlier suggestions around this. Why not use DCCP
with TFRC or TCP like congestion control tunneled over UDP.

The whole specification is ready. Which avoids any hiccup with the
transport people and IESG.

We can run either IP/UDP/DCCP/DTLS or specify the reverse if we want to
protect also DCCP headers by defining IP/UDP/DTLS/DCCP.

The main argument has been against implementation readiness of this
solution. I would note that any homegrown solution will also not be
implemented and available. And there do exist some stack implementations.

And when it comes to complexity, one will realize that most functions
are in fact needed anyway.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------