Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

A reminder:  If the JS specifically sets the SID when creating a data
channel, then it can receive data without getting an OPEN message.

I agree with Martin and Randell that the OPEN message must be sent
reliably.

I agree with Martin about in-order-ness and that the real question, if I
can put it in my own words, is: What does the browser do when it receives
data before an OPEN message for a SID that is not currently configured to
receive data (ie JS has not called create channel for that SID and we've
not received an OPEN for that SID)?

No matter what we specify as the correct behavior, the browser still has to
deal with this scenario, at the very least because of possibly erroneous or
even malicious senders.

It sounds like the answer appears to be "buffer until the OPEN".  But there
has to be a limit to how much we buffer.  What if the remote peer
accidentally or maliciously sends us 1GB of data and never sends an OPEN
message?  Then what does the browser do?

I think at that point, we either have to drop data or fire an event up to
JS letting it know.  I would suggest that after some buffer limit N, the
browser may fire .ondatachannel even if an OPEN message is not received,
and then deliver buffered data through the channel given in that event.
 The only alternative seems to be to just drop the data without telling the
JS.  Are there are any other alternatives I haven't thought of?

On Tue, Apr 16, 2013 at 9:11 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 15 April 2013 22:38, Randell Jesup <randell-ietf@jesup.org> wrote:
> > I disagree (though I suppose you don't *need* in-order, but it's a good
> > idea).
>
> In order delivery is not going to change anything.  It's neither good
> nor bad, it's straight up useless.  It's the ordering of the next
> packet that matters.  If that is marked for out of order delivery, it
> can be delivered to the application (in this case, I'm talking about
> the browser) before the open message.  Thus, the browser can (and
> will) receive messages prior to getting an open.
>
> The only safe assumption it can make at this point is that the channel
> is configured for out of order delivery.  Better to be silent about in
> order delivery and leave that for buffering.
>
> I do agree with you about reliability.  If you care about this message
> enough to have it sent, then you probably want retransmission.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>