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

["Olle E. Johansson" <[e-mail]>]

19 sep 2011 kl. 18:00 skrev Magnus Westerlund:

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

Just to throw in another abbreviation: MSRP

Isn't MSRP developed for this kind of sessions between users? Is there something in the protocol design that stops it from being p2p?

With MSRP, there's development experience as well as NAT traversal solutions.

/O