W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2014

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

From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Wed, 26 Mar 2014 18:11:32 +0100
Cc: Nicholas Wilson <nicholas@nicholaswilson.me.uk>, public-webrtc@w3.org
Message-Id: <9103EFA1-3715-4275-A236-8D939C67FFFE@lurchi.franken.de>
To: Wolfgang Beck <wolfgang.beck01@googlemail.com>
On 26 Mar 2014, at 17:50, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:

> 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?
Yes, but is is for the whole association, not for individual streams...
> 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
This is just a different API. And it won't give you per DataChannel flow control. If you want that,
you need a method that the receiver can signal its status to the sender. Please note that receiver
means a data channel...

Best regards
> Wolfgang Beck
Received on Wednesday, 26 March 2014 17:11:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:55 UTC