Re: [rtcweb] realiable data service

Cullen Jennings <fluffy@cisco.com> Mon, 18 July 2011 20:03 UTC

Return-Path: <fluffy@cisco.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 9E2C311E8070 for <rtcweb@ietfa.amsl.com>; Mon, 18 Jul 2011 13:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.156
X-Spam-Level:
X-Spam-Status: No, score=-104.156 tagged_above=-999 required=5 tests=[AWL=-1.557, BAYES_00=-2.599, 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 n8v5EgnLlEuw for <rtcweb@ietfa.amsl.com>; Mon, 18 Jul 2011 13:03:36 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 117AE228010 for <rtcweb@ietf.org>; Mon, 18 Jul 2011 13:03:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2697; q=dns/txt; s=iport; t=1311019416; x=1312229016; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RikcCOf5D9ExNSP/xox2PzlbNRqJhwDT8LTUKdO77vI=; b=kweWegVgBMLmnoI1DGAthvqvzr73tHf9IRKeB1wkRj/6L2z/aonfqbJs Q/kl16d25dyoWm83HLodbtYbdsVl6JbwfnWYajRuS54avBCs9EGEXJPnG WwKkQ8StKLsEUWFWGlRGFHSbvNp1rV/cF+IT4aMBHjgPQiUCuV126LvTU I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAN6QJE6rRDoH/2dsb2JhbABTp3p3iHylDJ4vhjwEh1SLEpB1
X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4088692"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2011 20:03:35 +0000
Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6IK3Y2p023923; Mon, 18 Jul 2011 20:03:35 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <47425BFC-EF8B-429C-BB51-764E856224B6@skype.net>
Date: Mon, 18 Jul 2011 13:03:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F25318E1-46DD-45A7-9515-894292936317@cisco.com>
References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <D1BE71E1-4F3B-474E-8A28-AA53CE6B684E@cisco.com> <47425BFC-EF8B-429C-BB51-764E856224B6@skype.net>
To: Matthew Kaufman <matthew.kaufman@skype.net>
X-Mailer: Apple Mail (2.1084)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] realiable data service
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, 18 Jul 2011 20:03:36 -0000

On Jul 18, 2011, at 11:52 , Matthew Kaufman wrote:

> 
> On Jul 15, 2011, at 8:51 AM, Cullen Jennings wrote:
> 
>> 
>> I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For non real time data, just dump it in dropbox of whatever your equivalent is and don't do it peer to peer. Unless someone has a real need, and wants to put forward a proposal, I don't see a need to focus energy on this right now. I'd rather work on the thing everyone agrees they do need which is the unreliable transfer. 
> 
> I'm personally torn on this one. I think that if we want to get something actually specified and deal with the majority of the use cases, we really need to focus on A/V and make data as simple as possible... that means unreliable datagrams with nothing but browser enforcement of rate via a simple congestion control algorithm.
> 
> On the other hand, if we go that route, people building things with the API will be forced to do it in Javascript... and all the arguments for putting ICE in the browser code instead of Javascript apply here, specifically that getting it right for N=# of browser implementations case is much more likely than getting it right for N=# of Javascript coders case.
> 
> But to get there probably requires solving many of the same set of problems that MFP and RTMFP solved, and that's a whole lot of specification and code to implement it, and we haven't even started on the agreement of which building blocks to start with (DCCP? SCTP? TCP over UDP?) much less gotten to a complete specification.
> 
> Unfortunately the right answer is probably to, once again, go to TSVAREA and state that a protocol that fits set of requirements would be really useful, and then not put it in browsers until it exists. There might be some value to making that ask in the form of a requirements document, but it needs to not be a "requirements of browsers for RTCWEB", instead it needs to be "requirements for a data transport protocol if a sophisticated one were to be added to RTCWEB in the future".
> 
> As I do remember most of the reasons we came up with MFP and RTMFP, I would be glad to contribute to such a requirements document.
> 
> But until then, I think we need *something* that lets data get from A to B over the direct unreliable channel.
> 
> Matthew Kaufman


I find myself on about the same page. I'd be happy to help go write up some requirement slides for the transport area.