Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Harald Alvestrand <[e-mail]>]

On 04/20/2013 05:18 AM, Randell Jesup wrote:
> 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.

File transfer protocol: OPEN, send data unordered with in-band file 
block positions, close.
If the OPEN packet gets lost, data will accumulate mighty fast.

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

Partial-reliable with max time for Open might be a very good idea.
>
>> 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.

Hmm. I wonder if this is really very easy to test: Tell the sending app 
you're not going to use OPEN, and tell the receiving app you're going to 
use OPEN. Send data.


>
>>   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]
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb