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

["MARCON, JEROME (JEROME)" <[e-mail]>]

 

> -----Message d'origine-----
> De : Michael Tuexen [mailto:[e-mail]] 
> Envoyé : mercredi 6 mars 2013 13:36
> À : MARCON, JEROME (JEROME)
> Cc : [e-mail]; 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:[e-mail]]
> >> Envoyé : lundi 4 mars 2013 19:47
> >> À : MARCON, JEROME (JEROME)
> >> Cc : [e-mail]; 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 : [e-mail]
> >> [mailto:[e-mail]] De la
> >>>> part de [e-mail] Envoyé : lundi 25 février
> >> 2013 23:40
> >>>> À : [e-mail] Cc : [e-mail] 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>> 
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>> 
> >> 
> >> 
> 
>