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
- [rtcweb] I-D Action: draft-ietf-rtcweb-data-chann… internet-drafts
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… MARCON, JEROME (JEROME)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Peter Thatcher
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Salvatore Loreto
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… MARCON, JEROME (JEROME)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… MARCON, JEROME (JEROME)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Salvatore Loreto
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… MARCON, JEROME (JEROME)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Salvatore Loreto
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… MARCON, JEROME (JEROME)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Michael Tuexen
- [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-… MARCON, JEROME (JEROME)
- Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-d… Harald Alvestrand
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Michael Tuexen
- [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-… MARCON, JEROME (JEROME)
- [rtcweb] RE : RE : I-D Action: draft-ietf-rtcweb-… MARCON, JEROME (JEROME)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-d… Randell Jesup