Re: [rtcweb] Endpoints that don't support RTCP

[Colin Perkins <[e-mail]>]

Emil,

I have repeatedly presented evidence, including measurements on real-world networks and simulations, to show that the proposal works. Varun and Zahed have also done tests and presented their results at IETF. 

You claim the circuit breaker doesn't work in some environments. I'm asking for details, so we can try to evaluate it in similar cases. That doesn't seem unreasonable. 

Colin



On 23 Apr 2015, at 06:31, Emil Ivov <[e-mail]> wrote:

> Colin,
> 
> Is it really that hard to see that the burden of providing performence evidence lies with the people advocating a solution? 
> 
> Please show me the data from all the real world deployments where you evaluated your mechanism and showed that it performed reasonably well!
> 
> Emil
> 
> On Thursday, April 23, 2015, Colin Perkins <[e-mail]> wrote:
> On 21 Apr 2015, at 11:53, Emil Ivov <[e-mail]> wrote:
>> Hey Harald,
>> 
>> On Tuesday, April 21, 2015, Harald Alvestrand <[e-mail]> wrote:
>> Den 21. april 2015 12:10, skrev Emil Ivov:
>> > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund
>> > <[e-mail]> wrote:
>> >> Emil Ivov skrev den 2015-03-30 23:00:
>> > So as I've mentioned before, I can see circuit breakers as an useful
>> > recommendation for some applications but they are definitely redundant
>> > in the context of WebRTC.
>> 
>> The purpose of circuit breakers is not to save the users from themselves.
>> 
>> It is to save the network from the users - to make sure that if WebRTC
>> users cause persistent congestion in the network, that congestion will
>> eventually go away.
>> 
>> Sure, I completely understand the intention. I just think CBs are a very crude attempt of achieving it. Also somewhat redundant in the context of WebRTC.
>> 
>> I have repeatedly asked for data that shows how CBs are beneficial in large-scale diverse deployments and so far I haven't seen any (I have even been asked by Colin to provide data that they don't work ... which is quite absurd :) )
> 
> The benefit is to the network, not to your application, of course. 
> 
> And yes, I am looking for cases where the circuit breaker interferes with real applications, because I want to understand if the circuit breaker is being over-sensitive, or if the applications are being unreasonable.
> 
>> This is the same purpose as the AIMD algorithm in TCP (which is not
>> particularly beneficial for each individual user).
>> 
>> Well ... it isn't really the same though is it. AIMD doesn't sadistically kill your connection at the first whiff of trouble ... :) ... it just MDs your bandwidth usage.
> 
> If the circuit breaker is working correctly, it won't "kill your connection at the first whiff of trouble". It's designed to stop flows that cause long-term and persistent congestion.
> 
> You earlier said:
> 
>> I am going to be *very* upset if my browser drops a call because of
>> 10% packet loss. I regularly have calls in hotel networks with up to
>> 20%+ regular packet loss and still enjoy productive conversations
>> thanks to FEC and PLC.
> 
> Give us some numbers: what packet size, data rate, and approximate RTT are being used for these calls with 10-20% packet loss, so we can evaluate if the circuit breaker will impact them?
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> 
> 
> -- 
> --sent from my mobile



-- 
Colin Perkins
https://csperkins.org/