Re: [rtcweb] realiable data service

Dzonatas Sol <dzonatas@gmail.com> Sat, 16 July 2011 17:41 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2921F8422 for <rtcweb@ietfa.amsl.com>; Sat, 16 Jul 2011 10:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeSN1L5-1Q3Y for <rtcweb@ietfa.amsl.com>; Sat, 16 Jul 2011 10:41:02 -0700 (PDT)
Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0E55121F8757 for <rtcweb@ietf.org>; Sat, 16 Jul 2011 10:41:02 -0700 (PDT)
Received: by pzd13 with SMTP id 13so3040055pzd.39 for <rtcweb@ietf.org>; Sat, 16 Jul 2011 10:41:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xt24TrW9NsBYgMqAKs/NozlpVeaI4hHUN5JGq6M1V0o=; b=J6jx5NQvv/alTzQd4s3sXLmbhYAmL9Wjswqhxv5uTCvVu9pv6T6od1uiuyAMy/SpW8 S7QDvD71zcv0X8tPDeBOWsBeMFKHJRa1eHe8dEEbtvu1gADb69x5sf4+ATzNb1I5CAkX PcYd2a8HpiB/3V814B34qX3OJuJj1bAsRiyUQ=
Received: by 10.68.62.36 with SMTP id v4mr6049793pbr.248.1310838061716; Sat, 16 Jul 2011 10:41:01 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id b4sm1338410pba.43.2011.07.16.10.41.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 10:41:00 -0700 (PDT)
Message-ID: <4E21CD2C.7080007@gmail.com>
Date: Sat, 16 Jul 2011 10:41:00 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: Dzonatas Sol <dzonatas@gmail.com>
References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <D1BE71E1-4F3B-474E-8A28-AA53CE6B684E@cisco.com> <4E21C9D3.7070306@gmail.com>
In-Reply-To: <4E21C9D3.7070306@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] realiable data service
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jul 2011 17:41:03 -0000

Another (independent) perspective is http://www.relayforlife.org 
<http://www.relayforlife.org/> on Second Life for current capability 
(and... accessibility). The common tether is the (already noted) Olympics.

On 07/16/2011 10:26 AM, Dzonatas Sol wrote:
> I'm sure I mentioned one case on another WG that oftens gets dropped. 
> The simple idea is to deliver content ahead of time by subscription to 
> an event. The content is then deemed reliably deployed at by the 
> schedule event. Last minute subscriptions are turned over to 
> unreliable. The subscription can be as simple as SMTP, so that 
> simplicity alone is why people drop and not look at it seriously enough.
>
> If you have over 10,000 people for an event with massive amounts of 
> pre-compiled content, then it makes sense to look at it more 
> seriously. The complexity is only what people perceive as static content.
>
> I hate to be the nag about such, yet protein topologies and 
> crystallization techniques already have vocab that describe such 
> ahead-of-time content delivery. The vocab is not accessible to 
> everybody, so this is often overlooked as something else.
>
> I don't see why we need to force pre-compiled content over real-time 
> services, especially unreliable, and expect something reliable. People 
> still do that, and it doesn't seem to be going away.
>
> ...as close as we can get to such use-case: start with the solution. =)
>
> On 07/15/2011 08:51 AM, Cullen Jennings 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  +46 10 7148287
>>>> F�r�gatan 6                | Mobile +46 73 0949079
>>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>>>> ----------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>> -- 
>>>
>>> Magnus Westerlund
>>>
>>> ----------------------------------------------------------------------
>>> Multimedia Technologies, Ericsson Research EAB/TVM
>>> ----------------------------------------------------------------------
>>> Ericsson AB                | Phone  +46 10 7148287
>>> F�r�gatan 6                | Mobile +46 73 0949079
>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>>> ----------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> Cullen Jennings
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>


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