Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Randell Jesup <[e-mail]>]

On 4/19/2013 8:32 PM, Bernard Aboba wrote:
> Peter Thatcher said:
>
> I like all the discussion, but I feel like we need to get back to the 
> question and what options we have.  The question: "what does the 
> browser do with unexpected data (before an open of an unregistered sid)?"
>
> 1. Buffer forever without limits:  Randell thinks it's OK to buffer 
> forever without limits.  Martin disagrees.  I disagree (I agree with 
> Martin).
>
> [BA] This seems like a bad idea.  If the receiver is expecting an OPEN 
> then it shouldn't allow an unlimited amount of (ordered!) data to be 
> received before getting one.

This case only applies in an un-ordered channel I believe, if we send 
the Open as reliable-in-order.  Ordered data must be delivered in-order 
(!), so the Open must be delivered before any following ordered data.  
(This is why I said the Open *should* be sent in-order; it removes the 
need to buffer in an ordered channel.)

>  If the receiver buffers a large amount of data and passes it to the 
>  JS even if the application indicated that an OPEN was required, this 
> might encourage implementations to bypass the OPEN, since receivers 
> are so tolerant about not getting it even if the application has 
> indicated it is required.

Well, if we do decide to timeout or size-out buffering of unordered 
early data, I wouldn't do so quickly.  My example for this would be a 
data-only application opening an channel just as it's fading out of 
WiFi/cell coverage, and hasn't picked up the new one yet (going through 
a tunnel, dead spot in the building, walk down to the basement, etc).

I would far rather the transaction 'freeze' and resume when a new 
connection is picked up (and ICE restart brings the connections alive 
again), than to have an arbitrary timer cause my app/game/etc to fail in 
a very very hard-to-test way.  In practical terms, it would be Very hard 
for significant data to end up buffered.  The application can deal with 
timeouts of the entire connection; I don't want to drop the data if the 
app has decided to stay in suspension waiting for a connection to 
resume.  After all, what is gained by dropping the data?  Don't say 
"knowledge that the channel failed to open" or "the connection is 
borked" - this isn't a good way to find out about total connection loss, 
and given we don't have timeouts on opens, I see no reason to insert 
them in an edge case for open for no useful reason.  If you want opens 
to timeout, that should be part of how Open works (partial-reliable with 
a max time), not indirectly-in-some-edge-cases like this.

> 2. Buffer with limits, and then:
>   a.  Hand an error to JS saying "got some data for a data channel, 
> but an OPEN never came" WITHOUT providing the data to JS: Harald likes 
> this.  I'm OK with this.
>
> [BA] One desirable aspect of this is that it (combined with a stream 
> reset) limits the potential for attacks or implementation problems to 
> affect applications.

Painful for implementers to test, and virtually impossible for 
application authors to test, even if they realize it's a possibility.

>   b.  Hand an error to JS saying "got some data for a data channel, 
> but an OPEN never came" WITH providing the data: I like this better, 
> since I don't see a reason not to give JS the data.
>
> [BA]  For the reasons described above, I think we could end up 
> regretting this option.

I agree, though for different reasons than Bernard.

-- 
Randell Jesup
[e-mail]