Re: WebRTC and backpressure (how to stop reading?)

On 03/26/14 17:01, Michael Tuexen wrote:
> On 26 Mar 2014, at 14:18, Nicholas Wilson <nicholas@nicholaswilson.me.uk> wrote:
>
>> On 26 March 2014 09:17, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>> Could you explain how you can the underlying SCTP channel supports
>>> backpressure per stream? SCTP supports a flow control which affects
>>> all streams, but not a flowcontrol per stream.
>> ..
> Please note that you could provide an JS API for this and let the
> Browser send some message to the peer which would result in stopping
> sending. These messages would not be visible to the JS user (same
> applies to the DCEP messages).
Why can't the browser do this?
- it maintains a receive queue for every JS data channel
- Whenever it receives a packet from an SCTP channel, it places it into 
the receive queue of the associated data channel.
- Whenever the JS reads from a data channel, it removes the packet from 
the data channel receive queue and hands it to the JS.
-  As long as the data channel receive queues are full (or their 
combined lengths exceeds some value), it stops receiveing
from the SCTP session, forcing backpressure which will eventually reach 
the sending browser.
- As long as there are packets in a receive queue, it signals this as an 
event to the JS.

SCTP already has a message that tells the sender to slow down, doesn't it?

On the sender the browser would have to do this:
- the browser maintains a send queue for every data channel.
- As long as the send queues are not full (or their combined lengths 
does not exceed some value), the JS can place a packet in them.
- Whenever SCTP is ready to send a packet, the browser selects a send 
queue, takes a packet from this queue, and sends it
over SCTP. You could even do weighted fair queueing this way.
- Whenever a data channel send queue has room for at least one packet, 
the browser signals this to the JS


Wolfgang Beck

Received on Wednesday, 26 March 2014 16:50:59 UTC