Re: [rtcweb] Lower-overhead protocol variations

Michael Tuexen <> Thu, 21 February 2013 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E21521F8BE0 for <>; Thu, 21 Feb 2013 05:03:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OPeseuoHkuQz for <>; Thu, 21 Feb 2013 05:03:49 -0800 (PST)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id 772AC21F8CB2 for <>; Thu, 21 Feb 2013 05:03:47 -0800 (PST)
Received: from [] (unknown []) (Authenticated sender: macmic) by (Postfix) with ESMTP id 981C91C0C069C; Thu, 21 Feb 2013 14:03:44 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tuexen <>
In-Reply-To: <>
Date: Thu, 21 Feb 2013 14:03:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Randell Jesup <>
X-Mailer: Apple Mail (2.1283)
Cc: "" <>
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 13:03:52 -0000

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
> 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
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?

Best regards
> negotiate additional streams on request, so this may not really matter.
> We may need to reserve more initial streams, but the overhead for this is
> minimal.
> Perhaps this would address some of the concerns voiced here.  Also,
> someone will be posting a use case soon this sort of change will
> help.... <jesup waits for the post>
> -- 
> Randell Jesup
> _______________________________________________
> rtcweb mailing list