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

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.
> 
> Oh dear - you're quite right! I hadn't looked at the code yet for the
> case of multiple data channels. The fact that each DataChannel runs
> over a single SCTP connection is a real nuisance then.
> 
> Let's imagine a complex app: someone's bound to implement a
> torrent-like protocol on top of WebRTC at some point, which would
> require several channels between peers. It's perfectly possible for an
> app to want to block reading from one of the channels, eg the user
> needs to select a download directory, or the application wants to show
> a warning or security prompt before continuing to read from the
> channel. We'd want to be able to continue to process data in the
> background from the other channels though.
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).
> 
>> It does not only have an ideal external interface, SCTP doesn't
>> provide a flowcontrol per stream. Not ready data on one stream
>> would affect the other streams...
> 
>> From my point of view then, the problem is using SCTP streams for the
> data channels, rather than opening a new SCTP association for each
> channel. We have every single port number available (because the port
> numbers used to distinguish SCTP connections are encapsulated, private
> to the WebRTC protocol).
> 
> What was the reasoning for using streams - simply to avoid the SCTP handshake?
You would have multiple SCTP associations, each running its own congestion
control and fighting with each other. As stated above, you can implement
what you want on top of SCTP, which doesn't mean that it has to be done
by the JS application writer...

Best regards
Michael
> 
> The port number can apparently be selected currently using a "data
> codec", some sort of a pseudo-codec with a port number property. I
> don't know if Chrome/Firefox use that? The SCTP port numbers are
> essentially unused, so I think it would be preferable just to make a
> new SCTP connection per channel, with the SCTP port set to
> `5001+$ssrc` (say). Then it would still be possible to change the base
> port to 6001 if the protocol gets bumped up.
> 
> This would be a breaking change only to applications using more than
> one data channel.
> 
> Regards,
> Nicholas
> 
> -----
> Nicholas Wilson: nicholas@nicholaswilson.me.uk
> Site and blog: www.nicholaswilson.me.uk
> 
>

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