Re: [rtcweb] Lower-overhead protocol variations

Salvatore Loreto <> Wed, 27 February 2013 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FD0421F8554 for <>; Wed, 27 Feb 2013 04:20:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.022
X-Spam-Status: No, score=-106.022 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HIDeU9bxobZN for <>; Wed, 27 Feb 2013 04:20:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E94FF21F852B for <>; Wed, 27 Feb 2013 04:20:17 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-41-512dfa00fda5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 4E.63.32353.00AFD215; Wed, 27 Feb 2013 13:20:17 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server id; Wed, 27 Feb 2013 13:20:16 +0100
Received: from ( []) by (Postfix) with ESMTP id 1C2C222E1; Wed, 27 Feb 2013 14:20:16 +0200 (EET)
Received: from (localhost []) by (Postfix) with ESMTP id CF3A254568; Wed, 27 Feb 2013 14:20:13 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost []) by (Postfix) with ESMTP id DC69053365; Wed, 27 Feb 2013 14:20:12 +0200 (EET)
Message-ID: <>
Date: Wed, 27 Feb 2013 14:20:14 +0200
From: Salvatore Loreto <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Stefan Håkansson LK <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+JvjS7jL91Ag2nfmC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuQzv9kKDqlWNHfXNDAek+1i5OSQEDCRmNwwkQnCFpO4cG89 WxcjF4eQwElGidkvJrKAJIQENjBKzOxIgkjsYpS41d3JCuGsZZR4+O85C4SzjVHiyve1YC28 AtoSj97uYgOxWQRUJSasuglmswmYSTx/uIUZxBYVSJb49+gII0S9oMTJmU/AekUE/CXmN+0A q2EWEJbYcLENLC4sYCHxsOcIE8SyH4wSmyZ8ZQdJcAroSEx9N40dosFW4sKc6ywQtrxE89bZ zBDPqUlcPbeJGeIfLYnes51MExhFZyHZPQtJ+ywk7QsYmVcxsucmZuakl5tvYgQG+cEtvw12 MG66L3aIUZqDRUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRmG1xVt/b/768XPe 4798L3zkGN//Vmo9e8YhrpDh3+2np/Q5fVx//du/OmxJ8dyOjl/r+Sx9ytVeTAqulG5We/xY f+3pn1e9GBXCbO9t75+08ZVn1tens+66e0/pttj18mpm3oZ3i/8qVU7kyGZZ1zF104/1rWu+ 3BTRm7j0X9v9+Y+SJVnPmCkrsRRnJBpqMRcVJwIAu+7RFUACAAA=
Subject: Re: [rtcweb] Lower-overhead protocol variations
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: Wed, 27 Feb 2013 12:20:20 -0000

On 2/25/13 2:57 PM, Stefan Håkansson LK wrote:
> On 2013-02-25 13:28, Harald Alvestrand wrote:
>> On 02/21/2013 09:19 PM, Michael Tuexen wrote:
>>> On Feb 21, 2013, at 3:54 PM, Randell Jesup wrote:
>>>> On 2/21/2013 8:03 AM, Michael Tuexen wrote:
>>>>> On Feb 20, 2013, at 10:31 PM, Randell Jesup wrote:
>>>>>> This is a relevant thread to current discussions:
>>>>>> and continued with subject change in
>>>>>> I'm re-evaluating if the original decision against even/odd was
>>>>>> required,
>>>>>> in order to see if we can collapse the current draft 0-RTT proposal
>>>>>> into a single declarative "open" message on a stream with no
>>>>>> response or ack
>>>>>> required. Even/odd (perhaps based on a property of the SCTP
>>>>>> association?)
>>>>>> would avoid the need for mismatched channel pairs, and thus avoid
>>>>>> the need
>>>>>> for the response/ack and the need to send with the in-order bit.
>>>>> I'm not sure what you mean you even/odd?
>>>>> I guess you will send the "open" message reliable and ordered. OK.
>>>>> Are you proposing that there is no ACK sent back? What would happen
>>>>> if one side sends an "open" message indicating an unordered data
>>>>> channel,
>>>>> sends a user message on this channel and the user message is 
>>>>> delivered
>>>>> first?
>>>> As you infer below, this would be one side uses even channels to
>>>> initiate, the other uses odd (to avoid glare).
>>>> The reliability question is important; the simplest solution would be
>>>> to buffer any data that arrives without an Open message until the
>>>> Open message is received, and then deliver it.  There's no issue in
>>>> the other direction, as once the open message is received the
>>>> receiver can then send on that stream/channel with no restrictions. I
>>>> assume there's some way to reliably choose roles for even/odd
>>>> selection in SCTP?  If not, we can find other ways to do it (even SDP
>>>> if we had to), though I think we could also key off the DTLS.
>>> Not sure we can choose based on SCTP. The port numbers can be the same
>>> and we have no addresses
>>> available. Maybe we can use the client/server identity from DTLS (the
>>> DTLS client uses even,
>>> the DTLS server uses odd).
>> The MMUSIC SCTP draft (draft-ietf-mmusic-sctp-sdp-03.txt) says:
>> 6.  The Setup and Connection Attributes and Association Management
>>     The use of the 'setup' and 'connection' attributes in the context of
>>     an SCTP association is identical to the use of these attributes in
>>     the context of a TCP connection.  That is, SCTP endpoints MUST 
>> follow
>>     the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
>>     the use of the 'setup' and 'connection' attributes in offer/answer
>>     [RFC3264] exchanges.
>> The relevant table from section 4 of RFC 4145 is:
>>             Offer      Answer
>>              ________________
>>              active     passive / holdconn
>>              passive    active / holdconn
>>              actpass    active / passive / holdconn
>>              holdconn   holdconn
>> I think that based on RFC 4145, it would be reasonable to say that the
>> party in the "active" role uses the even channels and the party in the
>> "passive" role uses the odd channels, and that if the initiator uses
>> "actpass", no channel assignment can be made until the answer comes back
>> as either "active" or "passive".
>> This, of course, implies that channel numbers are reassigned from a
>> blank slate if the connection goes down and is reestablished with new
>> values for active and passive. Probably one should say that if the
>> connection goes down, all channels go down too - that the data channel
>> system doesn't attempt to layer yet another layer of reconnection on top
>> of the already existing ones.
> I think so too. For WebSockets, you get the close event (with a reason 
> why it was closed [1]); the app has to establish a new one. The data 
> channels should have the same behavior IMO.
> [1] 
that is true,
but in WebSocket we decided to do so to avoid possible security hole,
I don't recall the possible security attack was depicted at time (it 
should be in the HyBi archive)
however I am not sure it would apply here (due to DTLS, security 
identity, consent etc etc)

having said that
making DataChannel to behave identically to WebSocket in this situation 
(i.e. the connection goes down and is reestablished)
it would simplify the implementation for sure