Re: [rtcweb] Data Channel Negotiation and reopening of decisions

Randell Jesup <randell-ietf@jesup.org> Sat, 16 February 2013 06:59 UTC

Return-Path: <randell-ietf@jesup.org>
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 EB4BD21F8570 for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 22:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599]
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 bmum0cePNxPQ for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 22:59:09 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 608C121F855C for <rtcweb@ietf.org>; Fri, 15 Feb 2013 22:59:09 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2223 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1U6bjo-000C5J-Jc for rtcweb@ietf.org; Sat, 16 Feb 2013 00:59:08 -0600
Message-ID: <511F2DB9.3040905@jesup.org>
Date: Sat, 16 Feb 2013 01:56:57 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnWUpMSBLioSD2+p82vGszX9R0Q4WFfME5j-DuK+B7KVJw@mail.gmail.com> <5113CD16.6090806@jesup.org> <CABkgnnW792o76t9dKhidOMJpa21VcbPQZFU1HYnY_yjTPCWhYw@mail.gmail.com> <51166A3C.4000604@jesup.org> <CABkgnnV2m=m+qtM1YR4CPse=gyekvWThon_Nxbf8YMVaNuvq6Q@mail.gmail.com> <511B6C9A.4090904@jesup.org> <CABkgnnUiCKuv_=mgLFf4sRnOb1bY190N7E_+V8gfTbKEUTBnDw@mail.gmail.com> <511CB20C.7020003@jesup.org> <CABkgnnU0idt+ntpKjTCMUCVFO9=_fSjGRPikD6Nk_Uem3L7E8g@mail.gmail.com> <89FAFB5C-9D03-4B76-A306-01F9E4EC4105@lurchi.franken.de> <CABkgnnXFrqTo2QpLhjWt5CmcQc6Kv4=vAgd3DgyndNtL1ewm7g@mail.gmail.com>
In-Reply-To: <CABkgnnXFrqTo2QpLhjWt5CmcQc6Kv4=vAgd3DgyndNtL1ewm7g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
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: Sat, 16 Feb 2013 06:59:10 -0000

On 2/14/2013 8:13 PM, Martin Thomson wrote:
>> However, assuming datachannel are bidirectional, I really think we need some
>> sort of signaling to set them up to avoid collisions.
> Collision of what?  The problem that the 1.5 RTT solves is not a
> collision problem.  It's a problem of a mismatch of configuration and
> expectations on the two ends of the channel.  If you remove the
> expectations (negotiate if you care), and don't worry about matching
> configuration (make configuration mutable, and again: negotiate if you
> happen to care), what then?

The 1.5 RTT solution was due to the W3 and IETF at Stockholm saying they 
wanted OnOpen events to only fire when we knew the other side had 
received them, IIRC, like WebSockets.

My 0-RTT solution I've (re-)proposed doesn't loosen any of the 
consistency guarantees; it merely fires onOpen as soon as the channel is 
created*.  You can send immediately.  This also means there's no need to 
signal channels in the SDP.  The only minor impact is that until the 
openResponse is received (1 RTT), packets are sent with the in-order 
flag.  There are some minor details that would need to change from the 
current protocol definition, but nothing of significance.

* createDataChannel before createOffer will not fire onOpen until the 
SCTP association comes up and onConnection has fired.

I think the "just send on the next channel and ignore glare and 
accidental channel merges" is just handing a loaded gun to the 
application writer, where it normally works fine but occasionally in 
hard-to-test ways it malfunctions.

If you want bidirectional channels, you either negotiate (SDP) or you 
use something like this (which allows mis-matched streams to build a 
channel).

-- 
Randell Jesup
randell-ietf@jesup.org