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

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! 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. 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?

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 17:58:59 UTC