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

On 27 Mar 2014, at 17:19, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:

> 
> On 03/27/14 11:38, Michael Tuexen wrote:
>> On 26 Mar 2014, at 18:58, Nicholas Wilson <nicholas@nicholaswilson.me.uk> wrote:
>> 
>> 
>> 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...
> How do you prevent such messages from being stuck in a congested SCTP queue? Is only one side allowed to send bulk data?
It might take some time to make it through the SCTP queues... And no, both sides can send data.
However, SCTP has to make sure that no data channels block the others. But you can have a
data channel and both sides send bulk data.
If you want, you could reserve a pair of SCTP streams, give them a high priority for
the stream scheduler. Then there would be no queue containing user data.
> How does this help with head of line blocking, when sender and receiver are faster than the network connection?
I'm not sure how this is related to HOL. There was a feature request such that
the receiver can signal to the sender that it doesn't want to receive anymore.
> 
> I stand by my proposal, let the browser keep the SCTP queues as empty as possible and maintain some queues towards the JS.
Isn't that up to the implementer? At least this does not require protocol mechanisms, or am I missing something?

Best regards
Michael
> 
> 
> Wolfgang Beck
> 
>

Received on Thursday, 27 March 2014 19:53:44 UTC