Re: [rtcweb] Non-media data service consensus and requirements

[Igor Faynberg <[e-mail]>]

At the interim meeting,  there was a strong argument for NOT having ICE 
as part of the browser, and I remember that no one objected.  My reading 
is that it has been the decision.

Igor


On 6/27/2011 6:43 PM, Emil Ivov wrote:
> ...
>> For these transactional exchanges the overhead of ICE would be excessive
>> and so there will be a very strong temptation to cut corners.
> Well, if ICE is part of the browser we could condition sending such data
> on the successful termination of ICE processing with the intended
> destination. Same as with RTP. Wouldn't this work?
>
> Emil
>
>> Assuming that the goal is not to send arbitrary data, then we need to
>> dig into the transport requirements more.
>>
>> For example, is the non-media data to be synchronized with media (e.g.
>> real-time text)?
>>
>> Is there a session associated with the non-media data (e.g. XMPP or MSRP
>> exchanges)?
>>
>> Is there a reliability requirement?
>>
>> Is it congestion-controlled?
>>
>> How long-lived are the flows?
>>
>>
>>
>>
>> ---------------------------------------------------
>> From: [e-mail]
>> To: [e-mail]
>> Date: Mon, 27 Jun 2011 09:36:30 +0200
>> Subject: [rtcweb] Non-media data service consensus and requirements
>>
>> WG,
>>
>> At the interim it was planned to have a bit discussion on the datagram
>> service for RTCWEB. The first question to try to resolve if there
>> is consensus for including some form of non real-time media (i.e. not
>> audio, video) service between peers. This is a bit tangled with the
>> actual requirements and use cases. But there was views both for it and
>> against it on the mailing list. So lets continue and try to come to a
>> conclusion on this discussion.
>>
>> The use cases mentioned on the mailing list are:
>>
>> - Dynamic meta data for Conference and other real-time services
>>
>> - Gaming data with low latency requirements
>>
>> Does anyone like to add additional use cases?
>>
>> Based on my personal understanding this points to primarily have the
>> RTCWEB provide a unreliable datagram service. This clearly needs
>> additional requirements to be secure and safe to deploy, but more about
>> this below. I still like to ask the WG here a question.
>>
>> Are you supporting the inclusion of a unreliable datagram service
>> directly between peers? Please provide your view and any additional
>> statements of motivation that you desire to provide.
>>
>> Secondly, there is a question if there needs to have something that
>> provides reliable message (of arbitrary size) or byte stream oriented
>> data transport between the peers. I personally foresee that people will
>> build JS libraries for this on top of a unreliable datagram service. If
>> you desire reliable data service as part of the standardized solution
>> please provide motivation and use case and requirements.
>>
>> I also want to take a stab on what I personally see as the requirements
>> that exist on unreliable datagram service in the context of RTCWEB.
>>
>> - Unreliable data transmission
>> - Datagram oriented
>>     * Size limited by MTU
>>       - Path MTU discovery needed
>>     * Fragmentation by the application
>> - Low latency, i.e. Peer to Peer preferable
>> - Congestion Controlled, to be
>>     * Network friendly
>>     * Not become a Denial of Service tool
>> - Security
>>    * Confidentiality
>>    * Integrity Protected
>>    * Source Authenticated (at least bound to the signalling peer)
>>    * Ensure consent to receive data
>>
>> Please debate the above. This is an attempt to ensure that we can
>> establish WG consensus on both data service and any requirements.
>>
>> 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]
>> ----------------------------------------------------------------------
>>
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb