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

[Randell Jesup <[e-mail]>]

On 11/11/2011 4:14 PM, Michael Tuexen wrote:
> On Nov 11, 2011, at 8:52 PM, Michael Thornburgh wrote:
>
>>>> o (most important for real-time communication): each user data fragment/chunk is assigned an SCTP Transmission Sequence Number (TSN) at the time of first transmission. that means even if your SCTP implementation supported stream prioritization somehow, the priority decision is only made at first transmission time. since there's just one TSN space and the Gap Ack structure only talks about TSNs, it's undesirable for gaps to persist (else the Gap Ack structure will continue to grow as more losses naturally happen). therefore it's desirable to repair gaps as quickly as possible. this may inappropriately increase the priority of a low priority fragment/chunk/stream during periods of congestion, which is exactly when priority matters (this is a "priority inversion").
>>> What might help is that messages have priorities and the sender is allowed to abandon messages
>>> with low priorities in case of congestion (timer based retransmissions). Something which is supported by PR-SCTP.
>> sure. but the problem here is the low priority stream is likely to be one that needs full reliability (like a bulk data transfer that you want to use "background" bandwidth but still eventually get delivered). in that case you don't want the sender to abandon the low priority message, and that's what leads to the priority inversion.
> So you want to send the bulk transfer with low priority but full reliability?


Yes, this would be quite common for things like background file 
transfers and data synchronization.

> And have some other messages, for example with high priority, but only limited reliability?
> You could do this. The only point: You need something to drop to improve things.


Yes, the background reliable flow *should* slow down, but it must remain 
reliable.  It would probably be ok if the background flow slowed down, 
and the high-priority flow also slowed down.

Note that we're talking about interactions with congestion-control here, 
and the algorithm can be modified (and we're talking about integrated 
congestion control between media and data anyways).

> Or do you want everything with full reliability?

No.

>> priority doesn't solve the problem at all. the issue is that if the receiver needs to stop accepting data on one stream, the only indication of reverse pressure to the sender is the association-wide receive window advertisement. the only in-protocol flow control is association-wide. the only solution is to not have the receiver suspend reading any stream and to use application-layer flow control to signal the sender to stop sending data on one stream or another.
> We have looked into this. Providing per stream flow control is hard to do as an extension
> to SCTP without introducing deadlocks. Looking at the SCTP socket API, there is a socket
> per association, so you can't read per stream. If you want signaling from the receiver,
> it must be done at the application layer. You can't use the flow control mechanism for that.

We can probably state that the app must deal with getting data for all 
streams; it can't decide not to service one stream of data, or implement 
application-level flow control.

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

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.

> So the problem is not, that SCTP does not provide a SSN for unordered DATA chunks,
> but that you use unordered messages instead of ordered and that currently you can't
> tell SCTP to deliver messages if they stayed for some time in the receive buffer.
> However, this is a receiver side only thing which could be done. This would be
> a local receiver side only modification supporting partial reliability. It could be
> done. It is more an API issue.


Right: After reading a datagram, do GetLastSerialNum() or some such.

> However, I would assume that this applies mostly to multi media stuff. Isn't RTP
> the protocol being considered for that?


Yes, and *we* don't plan to operate RTP jitter buffers through SCTP.  
But an application built on webrtc might, and certainly they may do the 
B, A, C stuff I mentioned above (and react in their app to whether there 
was any loss).


-- 
Randell Jesup
[e-mail]