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

[Dzonatas Sol <[e-mail]>]

Updated: medium path flow called either "petrifaction" or "cloud". I 
know there are better words, oh ya, "traits".

Trinary machines... enjoy.

On 07/13/2011 11:28 AM, Dzonatas Sol wrote:
> 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