Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Randell Jesup <[e-mail]>]

On 4/11/2013 7:04 PM, rtcweb issue tracker wrote:
> #13: Transport of DATA_CHANNEL_OPEN
>
>   Comment on draft-jesup-rtcweb-data-protocol:
>
>   All DATA_CHANNEL_OPEN messages MUST be sent reliably and in-order.
>
>   [BA] The DATA_CHANNEL_OPEN message is not acknowledged at the application
>   layer.  Therefore all that reliability and in-order delivery provides
>   (within the SCTP implementation) is the message was *received*, which
>   doesn't tell you if the message was acted on or not.  If you do support
>   app-layer acknowledgement to address this, then you don't need transport
>   reliability.
>

I disagree (though I suppose you don't *need* in-order, but it's a good 
idea).

Reliable delivery means that you won't have a problem of "Open message 
gets lost, all data packets get queued at receiver but never 
delivered".  Unless you have some meta-channel to tell the receiver that 
an open is on it's way, or add something to say " I have data but no 
Open", you want it to automatically retry to get the Open message 
through and unblock the channel.  This isn't about the sending-side 
application knowing the Open was received (in fact, this draft gives no 
way for the JS app to know that).

In theory because of the queue-on-data-before-open, you don't *need* 
in-order (and it only matters anyways if the channel is marked as 
in-order; otherwise it has no effect).  But I also see no reason for it 
not to be in-order in that case.

-- 
Randell Jesup
[e-mail]