Re: [rtcweb] Non-media data service consensus and requirements
Bernard Aboba <bernard_aboba@hotmail.com> Mon, 27 June 2011 22:35 UTC
Return-Path: <bernard_aboba@hotmail.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 BBBB51F0C49 for <rtcweb@ietfa.amsl.com>; Mon, 27 Jun 2011 15:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 y+jjSQbPjM3R for <rtcweb@ietfa.amsl.com>; Mon, 27 Jun 2011 15:35:14 -0700 (PDT)
Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by ietfa.amsl.com (Postfix) with ESMTP id C5C611F0C43 for <rtcweb@ietf.org>; Mon, 27 Jun 2011 15:35:10 -0700 (PDT)
Received: from BLU152-W31 ([65.55.116.74]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 15:35:10 -0700
Message-ID: <blu152-w313AC2093422E0C005708093570@phx.gbl>
Content-Type: multipart/alternative; boundary="_619c0170-1f0c-4026-ba0e-62b9c45533cd_"
X-Originating-IP: [131.107.0.111]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: rtcweb@ietf.org
Date: Mon, 27 Jun 2011 15:35:10 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jun 2011 22:35:10.0661 (UTC) FILETIME=[7940BF50:01CC351A]
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: Mon, 27 Jun 2011 22:35:18 -0000
I do not support an unreliable datagram service that can be used to send arbitrary data. For example, it seems dangerous for a Web browser under the control of an attacker to be able to send RIP, SNMP or DNS packets to arbitrary destinations. For these transactional exchanges the overhead of ICE would be excessive and so there will be a very strong temptation to cut corners. Assuming that the goal is not to send arbitrary data, then we need to dig into the transport requirements more. For example, is the non-media data to be synchronized with media (e.g. real-time text)? Is there a session associated with the non-media data (e.g. XMPP or MSRP exchanges)? Is there a reliability requirement? Is it congestion-controlled? How long-lived are the flows? --------------------------------------------------- From: magnus.westerlund@ericsson.com To: rtcweb@ietf.org Date: Mon, 27 Jun 2011 09:36:30 +0200 Subject: [rtcweb] Non-media data service consensus and requirements 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] 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