- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Sat, 29 Mar 2014 01:41:46 -0400
- 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