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

[Emil Ivov <[e-mail]>]

Colin,

On Thu, Apr 23, 2015 at 10:46 AM, Colin Perkins <[e-mail]> wrote:
> Emil,
>
> I have repeatedly presented evidence,

You inadvertently forgot to paste the link to these presentations. I
am particularly interested in the "real-world networks" ones.

> including measurements on real-world
> networks and

The one that I've seen is this:
http://csperkins.org/publications/2013/12/singh2013circuitbreaker.pdf

It discusses a testbed evaluation. That's certainly a useful first
step for a proof of concept sanity check but it is hardly more than
that.

> simulations,

Simulations are handy to evaluate very specific features of CBs in
very specific scenarios.

What we are discussing here is mandating mechanisms that have an
impact in a huge variety of networks.

> to show that the proposal works. Varun and Zahed
> have also done tests and presented their results at IETF.

Here too you forgot to paste the link. I am sure you wanted to be
helpful and this was not intentional, so could you please send them
over?

A quick google search with the names at site:ietf.org does not
immediately yield pointers to measurements on real-world networks.

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

I am claiming that we don't have sufficient evidence that they work
and am concerned that they would trigger in situations where common
sense dictates they shouldn't.

Now, I understand that our attitude is "we just need a backup plan on
paper because in practice everyone is going to have some sort of
congestion control anyway" and as such having circuit breakers lets us
sort of pretend we did our job. I am fine with this. Let's just try
not to forget it and treat CBs as rules set in stone (which is why I
made the commented that started this discussion).

Emil



> 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/
>
>
>
>



-- 
https://jitsi.org