Re: [rtcweb] Non-media data service consensus and requirements
Dzonatas Sol <dzonatas@gmail.com> Tue, 28 June 2011 20:49 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 5901C11E81BC for <rtcweb@ietfa.amsl.com>; Tue, 28 Jun 2011 13:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.363
X-Spam-Level:
X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, 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 Fu1MtwrLyouC for <rtcweb@ietfa.amsl.com>; Tue, 28 Jun 2011 13:49:16 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99D1911E814D for <rtcweb@ietf.org>; Tue, 28 Jun 2011 13:49:16 -0700 (PDT)
Received: by pwj5 with SMTP id 5so502201pwj.31 for <rtcweb@ietf.org>; Tue, 28 Jun 2011 13:49:16 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yD7ouvdQQV4DmQRvR+VqkYHPjrhKrLu+FKzi8PuVnLk=; b=llk+Wnuoena5kUpxk/Ysz14JqJgrkiYnc6eHxcSLoNOkVZs2FWaKo/Ky28Mj2KQ6XZ hadykXgcE/+5Z9WZo/0kIT9A/E/vcbEeZcaMkpuD55o3CCr9sb1KoEtosV9kX6hzRms4 RqOHU8z6vfHzg2NzFstZnrJyo6p8CisJKFIVM=
Received: by 10.68.35.2 with SMTP id d2mr3867743pbj.454.1309294156350; Tue, 28 Jun 2011 13:49:16 -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 o2sm384335pbj.1.2011.06.28.13.49.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Jun 2011 13:49:15 -0700 (PDT)
Message-ID: <4E0A3E1A.7070104@gmail.com>
Date: Tue, 28 Jun 2011 13:48:26 -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: rtcweb@ietf.org
References: <4E0832FE.7010401@ericsson.com> <4E0A2F70.9040305@jdrosen.net>
In-Reply-To: <4E0A2F70.9040305@jdrosen.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Non-media data service consensus and requirements
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: Tue, 28 Jun 2011 20:49:17 -0000
Please consider something like "augmented waypoints" for evacuation systems (might help resolve stampedes). On 06/28/2011 12:45 PM, Jonathan Rosenberg wrote: > Here are some thoughts on additional use cases: > > * information on congestion and receiver side environment for purposes > of improved sender rate adaptation > > * active speaker indications > > * real-time text (along the lines of > http://datatracker.ietf.org/doc/rfc5194/) > > * video controls - application driven intra-frame requests, for example > > * floor control requests/grants > > > All of these share the common property of being latency sensitive, and > thus more appropraite for p2p vs. server mediated. The other driver > for p2p data transport is cost reduction, to avoid the need for server > mediation for transfer of data. File transfer is the main example of > this. > > I view the latency-sensitive use cases as a higher priority for us and > a better match to the work we're doing here. > > Thanks, > Jonathan R. > > On 6/27/2011 3:36 AM, 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 > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant
- [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… Jonathan Rosenberg
- 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