Re: [rtcweb] realiable data service

[Justin Uberti <[e-mail]>]

At Google, we created a TCP/ICE-UDP layering to solve this exact problem,
using a user-mode implementation of TCP. It has some rough edges, but has
worked well in practice, and the code is freely available.

We know people will want/need a reliable messaging mechanism for p2p data.
While we can debate the details of this mechanism at length, I suspect
anything we choose will result in a better end-state than if we require
application developers to implement their own.

On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich
<[e-mail]>wrote:

>  +1
> Maybe it would be useful for the proponents of this and many other
> “desirable” features to think from the perspective if they would have to pay
> themselves for such developments and also make the code freely available.
> Cullen at least will make his code available.
>
> Thanks, Henry
>
>
>
> On 7/18/11 2:16 AM, "Serge Lachapelle" <[e-mail]> wrote:
>
> Hi Cullen,
>
> I agree with your push back.
>
> Focus is very important. Audio and video already present a huge challenge.
> (signalling, network, web developer friendly API, security, browser
> integration...)
>
> Also, I think that there is a real risk in introducing "duplicate"
> functionality in the browser as it may confuse web developers. There is a
> lot going on in HTML5...
>
> In my mind, this is "version 2.0" stuff.
>
> /Serge
>
>
> On Fri, Jul 15, 2011 at 17:51, Cullen Jennings <[e-mail]> wrote:
>
>
> I'd like to push back on the reliable service. I've yet to hear a use case
> for it that was real time. It's very hard to do a reliable real time
> protocol and we have seen zero proposal for this. For non real time data,
> just dump it in dropbox of whatever your equivalent is and don't do it peer
> to peer. Unless someone has a real need, and wants to put forward a
> proposal, I don't see a need to focus energy on this right now. I'd rather
> work on the thing everyone agrees they do need which is the unreliable
> transfer.
>
> Cullen <in my individaul contribut role>
>
> On Jul 13, 2011, at 8:57 , 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
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>