Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt

[Michael Tuexen <[e-mail]>]

On Mar 6, 2013, at 5:04 PM, Randell Jesup wrote:

> On 3/6/2013 10:03 AM, MARCON, JEROME (JEROME) wrote:
>> 
>>> 
>>> In this version, the sender sends an DATA_CHANNEL_OPEN as the first
>>> message and the receiver has to buffer user messages until the
>>> DATA_CHANNEL_OPEN message has been received in case of
>>> reordering in
>>> the network and using unordered delivery for user messages.
>>> 
>>> Best regards
>>> Michael
>>>> OK thanks. I am not sure to get your last point about order
>>>> of delivery. You seem to refer to the SCTP endpoint behaviors
>>>> (section 6.6) that unordered messages a) could bypass the
>>>> in-order messages in the outbound transmission queue and b)
>>>> must be delivered before in-order messages on the receiver side.
>>>> But then the DATA_CHANNEL_OPEN message should be sent
>>>> 'unordered'. Otherwise this situation could occur: the sender
>>>> app sends DATA_CHANNEL_OPEN 'in-order' and then immediately
>>>> many 'unordered' messages. Those messages would all bypass
>>>> the transmission of the DATA_CHANNEL_OPEN message.
> 
>>> That is why the receiver (the JS layer) has to buffer user
>>> messages if the DATA_CHANNEL_OPEN.
>>> You have no way to make sure the the DATA_CHANNEL_OPEN is the
>>> first one delivered on the receiver side, if the cannel
>>> provides unordered service. If the channel provides ordered
>>> delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that
>>> the JS layer gets them in the correct order. So one can send
>>> the DATA_CHANNEL_OPEN always ordered, but the receiving JS
>>> layer must be prepared to receive user message before it.
>>> It you want to avoid this, you need the solution in the older
>>> version of the ID, where you also send user messages ordered
>>> (even on an unordered channel) until you got a DATA_CHANNEL_RESPONSE.
>>> 
>>> Best regards
>>> Michael
>> I agree (in the context of your proposal) on the need for buffering user messages received on a closed channel. But still not sure about sending DATA_CHANNEL_OPEN 'in-order' always. Compare the results of setting or unsetting the Unordered bit:
>> 
>> 1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered last
> 
> I think you may be mis-reading RFC 2960 #6.6... I think in almost all cases, the OPEN would be received before the unordered data.  I think 6.6 means that unordered data following it *can* jump ahead of it in the reception buffer, though in practice I think that would only happen if the OPEN were blocked from being delivered by a missing ordered packet preceding it - which wouldn't exist in this protocol.
6.6. has no mandatory text on this... We push messages in the socket buffer as soon as we can. When they
are read by the application is up to the application.

The text allows you to bypass the ordering queue with an emphasis on preference to unordered messages.
But implementation details might come into the game.

Using a callback API allows to deliver as soon as possible, but if there is a socket buffer in the
game things might happen there...

Best regards
Michael
> 
> However, if this is incorrect, nothing would be harmed by sending OPENs for unordered channels in an unordered fashion, so long as they're reliable.
> 
>> 1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
>> 
>> 2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered first or in-between or last
>> 2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
>> 
>> So to me sending DATA_CHANNEL_OPEN 'unordered' is faster than - or as fast as - sending it 'in-order' (i.e 2a >= 1a). Sorry if I have missed something.
>> 
>> Observation: it seems suspicious in any case to receive an 'in-order' user message on a closed channel.
>> 
> 
> -- 
> Randell Jesup
> [e-mail]
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>