Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Michael Tuexen <[e-mail]>]

On Apr 21, 2013, at 2:34 AM, Harald Alvestrand wrote:

> 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.
If it gets dropped on the wire and transmission continues, it gets retransmitted roughly after an RTT.
The amount of data is limited by the socket buffer size of the peer.
> 
>>   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.
Which means you can't rely on getting an Open... Why not send the open request reliable and ordered. Send
all following user data ordered (no matter if the data channel is ordered or not) until the first message
of the peer is received.
This limits the amount of data to the local socket buffer size. You might have suboptimal performance
until a data message flows in the backwards direction, but that is the price for protection.

Using your example from above, I guess the receiver of the file sends requests for the block positions,
so it wouldn't hurt.

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