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

"MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com> Wed, 06 March 2013 15:04 UTC

Return-Path: <jerome.marcon@alcatel-lucent.com>
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 6239521F8A25 for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2013 07:04:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.924
X-Spam-Level:
X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 mnTPnc8oeDJ7 for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2013 07:04:11 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4271621F89E2 for <rtcweb@ietf.org>; Wed, 6 Mar 2013 07:04:11 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26F40UQ021289 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 16:04:09 +0100
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 16:03:43 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 6 Mar 2013 16:03:38 +0100
From: "MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Randell Jesup <randell-ietf@jesup.org>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqAgABEQ4CAAppZ0IAAIsyAgAAx2aA=
Date: Wed, 6 Mar 2013 15:03:36 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
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>
In-Reply-To: <1F61DA6E-21DD-43C3-8FC6-701E3B0ADDAF@lurchi.franken.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
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 15:04:12 -0000

 

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

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