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

On 03/26/2014 06:58 PM, Nicholas Wilson 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.
>
> That's possible, but it's a fairly major undertaking and might not be
> accepted by WebRTC implementors at this stage. The application-level
> window on each stream has to be equal to the SCTP window size for
> maximum throughput. Secondly, unless you're very careful then the
> application-level acks won't piggyback neatly onto the transports
> ACKS. That's a shame, but probably bearable?

>
> Regarding running two SCTP associations: you say each one will fight
> with other. Is that really a problem? We routinely open two TCP
> connections from one computer to another, almost every time I visit a
> webpage!
Actually you open up to 6-8 per server, depending on browser 
configuration, and it's considered a major problem with HTTP/1.1, and 
one of the major things that need fixing for HTTP/2.0.
>   TCP's fairness property means that (roughly,
> overall/eventually) two fully-loaded TCP connections over the same
> link will each get half the available bandwidth.
And if there are one browser using one TCP connection and one browser 
using eight TCP connections, the one using eight connections will get 
7/8 of the bandwidth. Or would, if HTTP transactions had lasted long 
enough to make TCP connections reach equilibrium. They don't.

>   Surely SCTP's
> congestion control achieves that as well. I would hope too that SCTP
> is TCP-fair, ie, if you run an SCTP connection on the same link as a
> TCP connection, they'll each take half the bandwidth. Some media
> protocols are not TCP-fair and converge to an equilibrium where the
> TCP connection has <10% of the bandwidth and that's a Bad Thing.
>
> So, I reckon using two SCTP associations should be viable. I'm much
> much more worried about the SCTP stream contending with the RTP stream
> than with other SCTP ones! The final alternative is to use not
> SCTP-proper, but instead a tweaked version that maintains per-stream
> windowing, or else adds a call to read data out of certain certain
> streams while leaving data still taking up space in the window for the
> blocked stream. But, if the SCTP-refimpl library is tweaked for use in
> WebRTC, that would make it harder to spec and to implement, so it
> doesn't sound like a great idea.
>
> CONCLUSION:
> * Three options: (1) two SCTP connections (2) data channel protocol on
> top of SCTP (3) use modified SCTP (undesirable)
> * I still think (1) should work and is easiest for WebRTC to spec and implement
> * (2) Should work but could be lots of effort
>
> I'm not an SCTP expert at all (in fact, reading through libusrsctp is
> my first real-world experience of it at all after reading Stevens UNP
> many years ago), so I'm happy to accept Michael's word for it as the
> author of the library! Do you know of a suitable protocol that already
> exists for adding per-stream flow control, without impacting
> latency/throughput too much? Or is there no existing protocol to do
> that which can take advantage of SCTP's features?

In fact, you might want to read up on HTTP/2.0 - especially why it's 
neccessary, and why it uses a single congestion-control connection 
between each client/server pair, not multiple ones.

>
> Thanks for the great feedback to my question so far!
>
> Nicholas
>
> -----
> Nicholas Wilson: nicholas@nicholaswilson.me.uk
> Site and blog: www.nicholaswilson.me.uk
>

Received on Wednesday, 26 March 2014 21:57:48 UTC