[rtcweb] Consensus Call on Non-media data service consensus and requirements

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 13 July 2011 15:57 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 BCCF621F8610 for <rtcweb@ietfa.amsl.com>; Wed, 13 Jul 2011 08:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.514
X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 AotuBzmR3FmI for <rtcweb@ietfa.amsl.com>; Wed, 13 Jul 2011 08:57:51 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 9A51921F8554 for <rtcweb@ietf.org>; Wed, 13 Jul 2011 08:57:50 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-41-4e1dc07dd96c
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain []) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.4B.09774.D70CD1E4; Wed, 13 Jul 2011 17:57:49 +0200 (CEST)
Received: from [] ( by esessmw0191.eemea.ericsson.se ( with Microsoft SMTP Server id; Wed, 13 Jul 2011 17:57:49 +0200
Message-ID: <4E1DC07B.7000807@ericsson.com>
Date: Wed, 13 Jul 2011 17:57:47 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E0832FE.7010401@ericsson.com>
In-Reply-To: <4E0832FE.7010401@ericsson.com>
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: [rtcweb] Consensus Call on 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: Wed, 13 Jul 2011 15:57:51 -0000


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.



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