Re: [rtcweb] Lower-overhead protocol variations

Stefan Håkansson LK <> Mon, 25 February 2013 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 411C121F8FA0 for <>; Mon, 25 Feb 2013 04:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.903
X-Spam-Status: No, score=-5.903 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zInul3XlNeNa for <>; Mon, 25 Feb 2013 04:57:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D6DF621F8F69 for <>; Mon, 25 Feb 2013 04:57:41 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-ff-512b5fc41d48
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E6.02.10459.4CF5B215; Mon, 25 Feb 2013 13:57:41 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 25 Feb 2013 13:57:40 +0100
Message-ID: <>
Date: Mon, 25 Feb 2013 13:57:40 +0100
From: Stefan Håkansson LK <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvje7ReO1Ag97trBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr42BfK0vBe8WKD4eWszQw7pXqYuTkkBAwkbi68D8bhC0mceHe eiCbi0NI4CSjxJU1Z6GctYwSE9v/M4JU8QpoSyzu/83UxcjBwSKgKvF6WghImE0gUOL6/19g YVGBKIkr+ywhqgUlTs58wgJiiwgIS2x91csEYgsLWEg87DnCBDH+BqNE3+zbYAlOAV2J5deP gjUwC9hKXJhzHcqWl9j+dg4ziC0EVPPu9T3WCYwCs5DsmIWkZRaSlgWMzKsY2XMTM3PSyw03 MQLD7OCW37o7GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY96J 7xOOcjgLSUzN599yoeC0if0CsZ1quzfVRhar7wyUqppfKvH8cGEAy8IvJX/yYw44NpdWnP3K rmDQuPd57/rpaxiUuMLOd4tl3NZamOq41Hyis73P5WPTy7SXTpT9eOVzEvP3mJU/2p8bV373 M1Kb8T13tvbBhO+6vV6dZg31M273eVcpKLEUZyQaajEXFScCAKSv2WgBAgAA
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: Mon, 25 Feb 2013 12:57:44 -0000

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.


>                     Harald
> _______________________________________________
> rtcweb mailing list