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

[Dzonatas Sol <[e-mail]>]

One more thing, the constraint on that reduce-reduce is the high path.

P.S. "noise-reduction", we do not get upset over "soft" patents for 
noise reduction, please do...

On 07/13/2011 10:08 AM, Dzonatas Sol wrote:
> Instead of "NAT traversal", can we reduce-reduce that term to 
> "synopsis". I've deleted my justification for that several times.
>
> On 07/13/2011 08:57 AM, Magnus Westerlund wrote:
>> Hi,
>>
>> I have reviewed the input both the last 2 weeks and the discussion back
>> in April.
>>
>> I see a strong support but with at least 2 people disagreeing to a basic
>> p2p datagram functionality. The use cases are various and some just
>> state that they see it as important functionality to provide to empower
>> the web application.
>>
>> Based on this I declare a rough consensus on that we should provide a
>> non-media data service that is unreliable datagram oriented directly
>> between the peers.
>>
>> One of objections against this was lack of clear requirements for what
>> the service. The straw men requirements I included has gotten some
>> discussion. Mostly support for them, but it is clear to me that we need
>> to further develop them. I would recommend the proponents for driving
>> proposals towards meeting this functionality to further discuss the
>> requirements taking the input so far into consideration.
>>
>> When it comes to reliable data transfer between peers there has been 4-5
>> that wanted the functionality, 2 additional that explicitly stated they
>> where okay with it. No additional that has stated against it.
>>
>> My interpretation is that we are close to having a rough consensus for
>> reliable data service, but we have so far seen no proponent willing to
>> suggest a solution for this. I would also note that a solution is likely
>> a functionality block that isn't dependent on more than the
>> signaling/negotiation and the NAT traversal and thus can be added a
>> later stage or be worked on with a completion date further into the
>> future than other pieces already.
>>
>> So for reliable data I would recommend that someone takes on the role of
>> proponent and provides a draft with their perceived requirements and a
>> straw man proposal for how to solve these requirements so we have
>> something more tangible to discuss.
>>
>> Cheers
>>
>> Magnus
>>
>> On 2011-06-27 09:36, Magnus Westerlund wrote:
>>> 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
>>>
>>
>
>


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant