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

[Emil Ivov <[e-mail]>]

На 28.06.11 14:52, Igor Faynberg написа:
> 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.

Well. I did attend the meeting but I remember no such decision or even
rough consensus. I actually remember people discussing the fact that
properly implementing ICE in javascript might be tricky due to the timer
granularity and the pacing requirements in 5245.

Have I missed something?

Emil

> 
> 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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[e-mail]                        PHONE: [phone]
http://jitsi.org                       FAX:   [phone]