Re: [rtcweb] Data transfer

[Magnus Westerlund <[e-mail]>]

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.

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

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

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