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

Randell Jesup <randell-ietf@jesup.org> Wed, 06 March 2013 16:05 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC6C21F85E8 for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2013 08:05:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIf+oDP6GulW for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2013 08:05:19 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id AE03921F85D8 for <rtcweb@ietf.org>; Wed, 6 Mar 2013 08:05:19 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:1892 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1UDGqF-000Gd7-4L for rtcweb@ietf.org; Wed, 06 Mar 2013 10:05:19 -0600
Message-ID: <5137690C.20105@jesup.org>
Date: Wed, 06 Mar 2013 11:04:28 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A020C70@FR711WXCHMBA02.zeu.alcatel-lucent.com> <1F61DA6E-21DD-43C3-8FC6-701E3B0ADDAF@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
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 - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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
randell-ietf@jesup.org