Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt

Randell Jesup <> Wed, 06 March 2013 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FC6C21F85E8 for <>; Wed, 6 Mar 2013 08:05:20 -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 AIf+oDP6GulW for <>; Wed, 6 Mar 2013 08:05:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AE03921F85D8 for <>; Wed, 6 Mar 2013 08:05:19 -0800 (PST)
Received: from ([]:1892 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1UDGqF-000Gd7-4L for; Wed, 06 Mar 2013 10:05:19 -0600
Message-ID: <>
Date: Wed, 06 Mar 2013 11:04:28 -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] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
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, 06 Mar 2013 16:05:20 -0000

On 3/6/2013 10:03 AM, MARCON, JEROME (JEROME) wrote:
>> In this version, the sender sends an DATA_CHANNEL_OPEN as the first
>> message and the receiver has to buffer user messages until the
>> DATA_CHANNEL_OPEN message has been received in case of
>> reordering in
>> the network and using unordered delivery for user messages.
>> Best regards
>> Michael
>>> OK thanks. I am not sure to get your last point about order
>>> of delivery. You seem to refer to the SCTP endpoint behaviors
>>> (section 6.6) that unordered messages a) could bypass the
>>> in-order messages in the outbound transmission queue and b)
>>> must be delivered before in-order messages on the receiver side.
>>> But then the DATA_CHANNEL_OPEN message should be sent
>>> 'unordered'. Otherwise this situation could occur: the sender
>>> app sends DATA_CHANNEL_OPEN 'in-order' and then immediately
>>> many 'unordered' messages. Those messages would all bypass
>>> the transmission of the DATA_CHANNEL_OPEN message.

>> That is why the receiver (the JS layer) has to buffer user
>> messages if the DATA_CHANNEL_OPEN.
>> You have no way to make sure the the DATA_CHANNEL_OPEN is the
>> first one delivered on the receiver side, if the cannel
>> provides unordered service. If the channel provides ordered
>> delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that
>> the JS layer gets them in the correct order. So one can send
>> the DATA_CHANNEL_OPEN always ordered, but the receiving JS
>> layer must be prepared to receive user message before it.
>> It you want to avoid this, you need the solution in the older
>> version of the ID, where you also send user messages ordered
>> (even on an unordered channel) until you got a DATA_CHANNEL_RESPONSE.
>> Best regards
>> Michael
> I agree (in the context of your proposal) on the need for buffering user messages received on a closed channel. But still not sure about sending DATA_CHANNEL_OPEN 'in-order' always. Compare the results of setting or unsetting the Unordered bit:
> 1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered last

I think you may be mis-reading RFC 2960 #6.6... I think in almost all 
cases, the OPEN would be received before the unordered data.  I think 
6.6 means that unordered data following it *can* jump ahead of it in the 
reception buffer, though in practice I think that would only happen if 
the OPEN were blocked from being delivered by a missing ordered packet 
preceding it - which wouldn't exist in this protocol.

However, if this is incorrect, nothing would be harmed by sending OPENs 
for unordered channels in an unordered fashion, so long as they're reliable.

> 1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
> 2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered first or in-between or last
> 2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
> So to me sending DATA_CHANNEL_OPEN 'unordered' is faster than - or as fast as - sending it 'in-order' (i.e 2a >= 1a). Sorry if I have missed something.
> Observation: it seems suspicious in any case to receive an 'in-order' user message on a closed channel.

Randell Jesup