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

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

From: Randell Jesup <randell-ietf@jesup.org>
Date: Sat, 29 Mar 2014 01:41:46 -0400
Message-ID: <53365D1A.8050501@jesup.org>
To: public-webrtc@w3.org
On 3/27/2014 6:38 AM, Michael Tuexen wrote:
> On 26 Mar 2014, at 18:58, Nicholas Wilson <nicholas@nicholaswilson.me.uk> wrote:
>> On 26 March 2014 16:01, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>> 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...
>> You're suggesting implementing a flowcontrol protocol on top of SCTP,
>> over which the data channels will run. Rather than mapping the data
>> channel messages byte-for-byte into the SCTP packets, the browser
>> would package them in some protocol of its own, so that per-stream
>> control was obtained.
> No. You could continue to map  the channel messages byte-by-byte
> on SCTP messages. But you would introduce some control message
> (also in SCTP DATA chunks) which you would send reliably and
> put in whatever information is needed. For me this looks pretty simple...

Agreed; we have considerable latitude to define additional control 
messages in DATA chunks, if we decide this is useful.
If we're careful, it may even be backwards compatible (ignored if not 
supported) without have to negotiate or probe for support.  But we'd 
need to know exactly *why* we'd consider changing things at this late 
date, and for what practical gain, given it would perhaps negatively 
impact the duck-typing between WebSockets and DataChannels and cause 
more delay and slow adoption.

And we also would need to know why an application-level protocol using a 
high-priority channel wouldn't serve the usecase.

Randell Jesup -- rjesup a t mozilla d o t com
Received on Saturday, 29 March 2014 05:42:28 UTC

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