Re: [rtcweb] Lower-overhead protocol variations

Randell Jesup <> Thu, 21 February 2013 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1361121F8E5A for <>; Thu, 21 Feb 2013 06:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sqRBTHFdZjx8 for <>; Thu, 21 Feb 2013 06:56:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 12FEF21F8E49 for <>; Thu, 21 Feb 2013 06:56:48 -0800 (PST)
Received: from ([]:1484 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1U8XZn-0003Kg-Fh for; Thu, 21 Feb 2013 08:56:47 -0600
Message-ID: <>
Date: Thu, 21 Feb 2013 09:54:26 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; 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-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
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: Thu, 21 Feb 2013 14:56:49 -0000

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.

>> The only hole I've seen so far is that if the return stream isn't
>> currently within the range of valid streams (i.e. at the far end) there's
>> no easy way to return an error.  However, we expect to be able to
> How are the stream in both directions tied together? How is the allocation
> done? Can't the sender of the "open" message know that there is no backward
> channel?

Actually, it probably can since it knows how many streams the other side 
can send with.   Some verbiage around how negotiation of the number of 
streams is done may be all we need here.  I don't see this as a major 

> Maybe you are thinking about each side only using even outgoing streams for
> data channels initiated by its own, and the next higher odd for the ones
> initiated by the peer. If you are thinking like this, each side knows if
> the resources are there and, if not, can request more. Do you have something
> like this in mind?

Yes.  I don't remember if you can request that the *other* side increase 
streams, but if we add verbiage that says "when a stream increase is 
requested by one side, the other side shall request a number of streams 
that large or larger" I think we're covered - then if the other side 
wouldn't have a return channel, you just request a stream increase 
(maybe even an increase of 0 streams, but that would require the other 
side to equal you).

Randell Jesup