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
- Re: [rtcweb] Non-media data service consensus and… Jonathan Rosenberg
- [rtcweb] Non-media data service consensus and req… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Bernard Aboba
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Matthew Kaufman
- Re: [rtcweb] Non-media data service consensus and… Christopher Blizzard
- Re: [rtcweb] Non-media data service consensus and… Bernard Aboba
- Re: [rtcweb] Non-media data service consensus and… Matthew Kaufman
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Igor Faynberg
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Manuel Simoni
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Igor Faynberg
- Re: [rtcweb] Non-media data service consensus and… Timothy B. Terriberry
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Randell Jesup
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Manuel Simoni
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Christopher Blizzard
- Re: [rtcweb] Non-media data service consensus and… Cullen Jennings
- Re: [rtcweb] Non-media data service consensus and… Cullen Jennings
- Re: [rtcweb] Non-media data service consensus and… Randell Jesup
- [rtcweb] Consensus Call on Non-media data service… Magnus Westerlund
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Magnus Westerlund
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Ted Hardie
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Silvia Pfeiffer
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Magnus Westerlund
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Ted Hardie
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Matthew Kaufman
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Magnus Westerlund
- Re: [rtcweb] realiable data service Henry Sinnreich
- Re: [rtcweb] realiable data service Justin Uberti
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Stefan Håkansson LK
- Re: [rtcweb] realiable data service Emil Ivov
- [rtcweb] PseudoTCP implementation (Re: realiable … Harald Alvestrand
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Bernard Aboba
- Re: [rtcweb] realiable data service Peter Saint-Andre
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Cullen Jennings
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Tim Panton
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Emil Ivov
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Cullen Jennings
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Harald Alvestrand
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti