[rtcweb] Non-media data service consensus and requirements

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 27 June 2011 07:36 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 03B6011E8086 for <rtcweb@ietfa.amsl.com>; Mon, 27 Jun 2011 00:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EGzseyRGB3PA for <rtcweb@ietfa.amsl.com>; Mon, 27 Jun 2011 00:36:35 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 2956411E8081 for <rtcweb@ietf.org>; Mon, 27 Jun 2011 00:36:35 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-96-4e083301fe87
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain []) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AA.D7.09774.103380E4; Mon, 27 Jun 2011 09:36:33 +0200 (CEST)
Received: from [] ( by esessmw0237.eemea.ericsson.se ( with Microsoft SMTP Server id; Mon, 27 Jun 2011 09:36:33 +0200
Message-ID: <4E0832FE.7010401@ericsson.com>
Date: Mon, 27 Jun 2011 09:36:30 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: [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 07:36:36 -0000


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.


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