Re: [rtcweb] Non-media data service consensus and requirements

Emil Ivov <> Mon, 27 June 2011 14:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B528E21F8603 for <>; Mon, 27 Jun 2011 07:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tg1D5GakEx+U for <>; Mon, 27 Jun 2011 07:26:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6442221F8595 for <>; Mon, 27 Jun 2011 07:26:13 -0700 (PDT)
Received: by wwe5 with SMTP id 5so3194452wwe.13 for <>; Mon, 27 Jun 2011 07:26:12 -0700 (PDT)
Received: by with SMTP id u53mr923472wec.96.1309178059734; Mon, 27 Jun 2011 05:34:19 -0700 (PDT)
Received: from porcinet.local ( []) by with ESMTPS id h43sm2742217wes.35.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 05:34:18 -0700 (PDT)
Message-ID: <>
Date: Mon, 27 Jun 2011 14:34:16 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Magnus Westerlund <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] Non-media data service consensus and requirements
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2011 14:26:14 -0000

На 27.06.11 09:36, Magnus Westerlund написа:
> 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?

- File transfer? Skype, Google Talk, Windows Live, and pretty much any
existing service has it so I suppose it is reasonable to assume that
people using rtcweb would like to add the feature to their web applications.

- Transferring input events (e.g. pressed keys and mouse clicks) in
desktop sharing applicaitons?

> 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.

Yes. Requirements and code necessary to support a generic datagram
service would hardly differ from those we have for RTP and it would
definitely help a lot in the use cases described above.

> 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 definitely think it would be a great idea for the IETF to specify a
datagram based reliable service similar to Google's pseudo TCP. Whether
or not this happens in RTCWEB is of course a different matter. As I
wrote above many applications are likely to need such a think and I am
not sure that the flexibility we'll get by leaving this to JS libs is
worth the interoperability nightmare it would imply.


> 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:
> ----------------------------------------------------------------------
> _______________________________________________
> rtcweb mailing list

Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi                        PHONE: +                       FAX:   +