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