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

[Dzonatas Sol <[e-mail]>]

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