Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt

[Randell Jesup <[e-mail]>]

On 11/12/2011 4:00 PM, Michael Tüxen wrote:
> On Nov 12, 2011, at 1:14 AM, Randell Jesup wrote:
>>>>>> o the semantics of unordered messages are confusing and not a good map to WebRTC. they are semantically equivalent to an entirely separate stream loosely associated to the ordered stream of the same number. there's no way to tell (without application layer sequencing) if an unordered message has been lost/abandoned by the sender. at the protocol level, TSNs can be used to recover the queuing order of received unordered messages, but the TSNs are semantically disconnected from the SCTP user. recovering the original queuing order over a short reorder/reassembly window period is desirable in some real-time applications.
>>>>> The concept of PR-SCTP is that the receiver can handle this. Since the sender decided that the sequencing
>>>>> is not important, why should be receiver care?
>>>> my main point was that, specifically in the case of PR-SCTP, since unordered messages don't have a stream sequence number there's no way to tell at the receiver if one (or more) has been abandoned. gaps in the ordered message space can be detected.
>>> Conceptual question: Why does unordered  data need some ordering information.
>>> It sounds to me that you don't have unordered stuff in mind, but ordered unreliable stuff.
>>
>>
>> Because of state:  If you have datagrams A, B, C, and it's delivered B, A, C, you may throw away A *if* the data in A was already provided or updated in B, but not throw it away if B and A are independent.  You need to know the original ordering to know that.  Games will do stuff like this.
> This means that there are sequencing constraints... So it is not unordered. I think
> the service is ordered, unreliable what is used...

To be utterly clear: the game example I gave requires unordered, 
unreliable (though unordered reliable and unordered partial-reliability 
would work too).  It also needs to know the original sequence to know if 
there are gaps or out-of-order deliveries.  If it doesn't get the 
original sequence information from the stack (i.e. know if a packet has 
a gap in delivery, or a packet is out-of-order (and ideally where in the 
sequence it belonged), then it must add it's own message serial numbers 
to the application data.

Any sequence constraints as described might apply to parts of the 
message, not only to the message as a whole.  How to handle this is 
entirely in the application domain.

>>
>> Also, with datagrams you may need to know about losses when in-order (gaps), to change how you process data (simple example: PR-SCTP for lossy audio; on a missing packet you synthesize a replacement instead of ignoring the loss.)
>>
>> Yes, these can be done with application sequence numbers (so long as out-of-order delivery is allowed).  It's moderately inefficient to do so if the sequence data is available in the protocol.
>>
>>>>>> o an SCTP receiver should be able to choose to receive stream messages in originally-queued order or as-received-on-the-network order on a per-stream basis, and be able to recover the original queuing order to whatever extent desired (potentially limited by real-time constraints) when receiving in network order. SCTP's unordered message semantics are designed for "out-of-band" messages, and are not a good fit for general "real-time" data. transmission order should be determined by the sender, reception order should be determined by the receiver.
>>>>> It is a sender side thing. If the sender requires in-sequence delivery, you want the receiver to ignore
>>>>> this requirement? If there is not sequencing constraint, the sender should not send it ordered.
>>>> it's natural to use unordered messages for real-time data, since they can be delivered to the user as soon as they arrive even if there are gaps. however, in exactly these real-time scenarios, it's still often useful to know the original queuing order of the messages, and to allow the receiver to partially recover the original queuing order in, for example, a jitter/reorder buffer. this can be accomplished with application-layer sequence numbers, but it seems silly to have to duplicate existing protocol-level functionality (see my point about flow control above).
>>> Hmm. Looking at the service you want doesn't seem be unordered. For me this looks like
>>> an ordered unreliable service, taking some timing requirements into account.
>>
>>
>> A jitter buffer is in fact inherently an in-order partial-reliability service, true - but with different characteristics from SCTP partial-reliability (adaptive to the jitter level, perhaps to appearance of spikes or bulk-delay changes, concealment, whether it's isochronous in output, etc).  As mentioned before, there are other uses of true out-of-order delivery.
> I think the point is:
> The service used us unreliable, ordered. And the application want to do the
> ordering by itself. So it should do so. Which includes providing the necessary
> information for it.

Sure it can provide the information itself.  It is a waste of bits since 
the stack knows the information, but it's only a minor waste (16 or 32 
bits per datagram).  We certainly can deal with that if the stack 
doesn't supply it.


-- 
Randell Jesup
[e-mail]