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

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...
> 
> 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
Didn't you say that you want to limit the sending rate? Or even
stop the sender? So that window would be less than what is allowed
by the SCTP congestion control.
> application-level acks won't piggyback neatly onto the transports
> ACKS. That's a shame, but probably bearable?
I wouldn't use transport level ACKS. Just messages like
* Stop sending on this data channel
* Send no more than n messages per second
* whatever is necessary to implement the required API...
> 
> 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,
Sure. Two would be fine. Please note that the number of stream opened
on association setup is about 65535!
> 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.
The currently defined SCTP congestion control is TCP fair. But this
doesn't work well for a larger number of associations. There are
also other benefits when running the multiple data channels over a
single SCTP association, like much better fast retransmissions for example.
> 
> 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
That is something to consider... But is it much easier to interact
with a single congestion control than to 65535 congestion controls...
> 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)
Why two? I don't understand where this limit comes from. (2) would
be an addon. But it would be important to know what the API looks
like...
> * 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?
Again I don't get you point: You wanted in another mail that the receiver
can tell the sender to stop sending. You can have a simple control message
and that would obviously impact the latency of the affected data channel.
Other channels wouldn't be affected.

Best regards
Michael
> 
> 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 Thursday, 27 March 2014 13:44:43 UTC