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

[Randell Jesup <[e-mail]>]

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.

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]