Re: [rtcweb] realiable data service

[Dzonatas Sol <[e-mail]>]

I suspect that TCP becomes the new semantic word for all browsers, as 
otherwise the movement of TCP to user-mode is already evident, and 
redundantly done (as suggested). TCP was the default way for developers 
to find stream-modes. Portability, like this, misrepresents needs beyond 
beginner layers.

Despite change, UDP over HTTP over S/MIME appears proper and quick 
enough (i.e. "can harden"). Path of least resistance... SSRC already 
offers that bit of available change and overlap. The question for 
standard besides mux is only expect RTP first or use OPTIONS to 
downgrade HTTP. We've used 1xx to bypass HTTP/TCP layers before, so in 
fairness I don't think this is correct for rtcweb in regards to states.

Implementation at software level seems futile if that concept is really 
that hard. We need non-encrypted unshrunken headers. Either that or 402 
out of no-where simply bytes for energy alone... a security disaster. I 
usually stay quiet about that, yet please note that harvesters are this 
artificially intelligent now. =)

On 07/19/2011 08:58 AM, Justin Uberti wrote:
> 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] <mailto:[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]
>     <http://[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] <http://[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> 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