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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Wed, 06 March 2013 16:26 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 DB5A321F8AC3 for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2013 08:26:12 -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 oLy21lgDlRet for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2013 08:26:12 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 6604721F89E9 for <rtcweb@ietf.org>; Wed, 6 Mar 2013 08:26:11 -0800 (PST)
Received: from [192.168.1.102] (p508FB97F.dip.t-dialin.net [80.143.185.127]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C69BB1C0C069D; Wed, 6 Mar 2013 17:26:08 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Date: Wed, 06 Mar 2013 17:26:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C146A5D8-D876-4902-B1CE-9447D8B5169E@lurchi.franken.de>
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>
To: "MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.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:26:13 -0000

On Mar 6, 2013, at 4:03 PM, MARCON, JEROME (JEROME) wrote:

> 
> 
>> -----Message d'origine-----
>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] 
>> Envoyé : mercredi 6 mars 2013 13:36
>> À : MARCON, JEROME (JEROME)
>> Cc : rtcweb@ietf.org; Randell Jesup
>> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>> 
>> On Mar 6, 2013, at 11:05 AM, MARCON, JEROME (JEROME) wrote:
>>> 
>>> Thanks Michael, I still have a question/comment inline.
>>> 
>>>> -----Message d'origine-----
>>>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>>>> Envoyé : lundi 4 mars 2013 19:47
>>>> À : MARCON, JEROME (JEROME)
>>>> Cc : rtcweb@ietf.org; Randell Jesup
>>>> Objet : Re: [rtcweb] I-D Action: 
>>>> draft-ietf-rtcweb-data-channel-04.txt
>>>> 
>>>> On Mar 4, 2013, at 3:36 PM, MARCON, JEROME (JEROME) wrote:
>>>> 
>>>>> 
>>>>> Randell,
>>>>> 
>>>>> Thanks for this update. There are some points not (yet)
>>>> explained in the text:
>>>>> 
>>>>> 1. Following the SDP opening handshake, are the data
>>>> channels implicitly opened, or does the offerer send one 
>>>> DATA_CHANNEL_OPEN message per new data channel ?
>>>>> 
>>>>> 2. "channel is available to send as soon as the
>>>> DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?
>>>> The SACK is an SCTP level ack. So you only know that the 
>> SCTP stack 
>>>> of the peer has received it, so you don't know if the 
>> application has 
>>>> received it or even processed it. So if you want some sort of ack, 
>>>> you need an application level ack.
>>>> This was done in the 3 way handshake stuff which was in the older 
>>>> version.
>>>> 
>>>> 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
No. If the DATA_CHANNEL_OPEN is received first by SCTP, it will be received first by the App.
> 
> 1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
Correct.
> 
> 2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered first or in-between or last
Correct.
> 2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
No. If the ordered message is received first, it gets delivered first.

Please note that the network layer might reorder packets or packets get lost and needs to be retransmitted.

Best regards
Michael
> 
> 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.
> 
>>> 
>>>>> 
>>>>> 3. Assuming an endpoint creating a new offer (e.g. to
>>>> reflect a change in media streams) while an SCTP association is 
>>>> already established. In this case, what does the SCTP association 
>>>> m-line contain: the unchanged list of data channels 
>> contained in the 
>>>> initial offer (which created the SCTP association), or the list of 
>>>> data channels currently opened, or .. ?
>>>>> 
>>>>> 4. What happens if the SDP Opening Handshake agreed on some
>>>> data channels using the 'chat' subprotocol, and later on 
>> an endpoint 
>>>> creates in-band a new channel with 'file transfer'
>>>> subprotocol ?
>>>>> 
>>>>> Jerome
>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De : rtcweb-bounces@ietf.org
>>>> [mailto:rtcweb-bounces@ietf.org] De la
>>>>>> part de internet-drafts@ietf.org Envoyé : lundi 25 février
>>>> 2013 23:40
>>>>>> À : i-d-announce@ietf.org Cc : rtcweb@ietf.org Objet : 
>>>> [rtcweb] I-D
>>>>>> Action: draft-ietf-rtcweb-data-channel-04.txt
>>>>>> 
>>>>>> 
>>>>>> A New Internet-Draft is available from the on-line 
>> Internet-Drafts 
>>>>>> directories.
>>>>>> This draft is a work item of the Real-Time Communication in 
>>>>>> WEB-browsers Working Group of the IETF.
>>>>>> 
>>>>>> 	Title           : RTCWeb Data Channels
>>>>>> 	Author(s)       : Randell Jesup
>>>>>>                        Salvatore Loreto
>>>>>>                        Michael Tuexen
>>>>>> 	Filename        : draft-ietf-rtcweb-data-channel-04.txt
>>>>>> 	Pages           : 13
>>>>>> 	Date            : 2013-02-25
>>>>>> 
>>>>>> Abstract:
>>>>>> The Web Real-Time Communication (WebRTC) working group 
>> is charged 
>>>>>> to  provide protocol support for direct interactive rich
>>>> communication
>>>>>> using audio, video, and data between two peers' 
>>>> web-browsers.  This
>>>>>> document specifies the non-media data transport aspects of the 
>>>>>> WebRTC  framework.  It provides an architectural overview of how
>>>> the Stream
>>>>>> Control Transmission Protocol (SCTP) is used in the 
>> WebRTC context 
>>>>>> as  a generic transport service allowing Web Browser to exchange 
>>>>>> generic  data from peer to peer.
>>>>>> 
>>>>>> 
>>>>>> The IETF datatracker status page for this draft is:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel
>>>>>> 
>>>>>> There's also a htmlized version available at:
>>>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-04
>>>>>> 
>>>>>> A diff from the previous version is available at:
>>>>>> 
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-04
>>>>>> 
>>>>>> 
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>> 
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>> rtcweb@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>> 
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> rtcweb@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>> 
>>>> 
>>>> 
>> 
>>