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

Randell Jesup <randell-ietf@jesup.org> Sat, 16 February 2013 17:17 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 1C12B21F846B for <rtcweb@ietfa.amsl.com>; Sat, 16 Feb 2013 09:17:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 mtdY-JSIi332 for <rtcweb@ietfa.amsl.com>; Sat, 16 Feb 2013 09:17:41 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC1E21F8468 for <rtcweb@ietf.org>; Sat, 16 Feb 2013 09:17:41 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3074 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 1U6lOK-0006o9-Sx for rtcweb@ietf.org; Sat, 16 Feb 2013 11:17:37 -0600
Message-ID: <511FBEAC.4070605@jesup.org>
Date: Sat, 16 Feb 2013 12:15:24 -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> <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> <8E2722E7-F82A-48D4-80FB-C76929A2E324@lurchi.franken.de> <CABkgnnWzX2tpbadnB3DjhmB7cm6poCDvmxdAW2Z_stMbovJ3gw@mail.gmail.com> <A0FDFC7C-2C85-431C-A03E-0E486F9378D1@lurchi.franken.de>, <CABkgnnWdjV7F9jkbap91q-pLygzWJsTvAOh-m=-9q4VrU9DGUg@mail.gmail.com> <DA07C056-3E80-4E30-B078-5547A174549D@skype.net>, <6106C927-127F-4514-A688-3BC138B0C4B3@lurchi.franken.de> <6D8A7B42-C24C-405D-B5A0-6A95F6F52554@skype.net>
In-Reply-To: <6D8A7B42-C24C-405D-B5A0-6A95F6F52554@skype.net>
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 17:17:42 -0000

On 2/16/2013 10:33 AM, Matthew Kaufman (SKYPE) wrote:
> Can you describe the "simple protocol to realize bi-directional data channels by combining two uni-directional streams" without referring to any of what now appear to be unresolved issues?

Let me try to succinctly summarize the low-level protocol (details are 
in the draft).  This is the wireline protocol, which can support 0 RTT 
usage.  It's pretty darn simple as protocols go.

This assumes the association has been created.

1) when one side wishes to open a channel with a given set of 
characteristics (label, IANA websockets-protocol, reliability options), 
it selects an unused outgoing stream X and sends Open on stream X.

1a) the Channel is now open on the sender's side and can be used for 
send(); but note that until an OpenResponse is received, the in-order 
bit will be set on any data packets

2) when an Open request is received (on any stream not already in-use), 
a reverse-direction outgoing stream Y is selected.  An OpenResponse(X) 
is sent on stream Y, and the application is notified a stream has been 
created.

2a) the Channel is now open on the receiver's side and can be used for 
send(), but note that until an ACK is received, the in-order bit will be 
set on any data packets.

3) when an OpenResponse(X) is received on an unused channel (Y), it's 
paired with X, and an ACK is sent on X.  The in-order bit is no longer 
forced on.

4) when an ACK is received on a channel, the in-order bit will no longer 
be forced on when sending data.


And that is basically it.

> On Feb 16, 2013, at 7:23 AM, "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de> wrote:
>
>>> None if this would be a problem if we weren't making the mistake of using SCTP, which itself made the mistake of doing full-duplex channels instead of unidirectional channels with optional one-to-one or even many-to-one associations (as RTMFP has, as an example)
>> SCTP streams uni-directional. That is why we use a simple protocol to realize bi-directional
>> data channels by combining two uni-directional streams.
>> SCTP association, however, are point-to-point. The API (1-to-many style) allows sending
>> a single messages (a single send() call) on all associations belonging to that socket.
>>


-- 
Randell Jesup
randell-ietf@jesup.org