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

[Colin Perkins <[e-mail]>]

Emil,

On 23 Apr 2015, at 10:38, Emil Ivov <[e-mail]> wrote:
> 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.

They're in the IETF proceedings, for example AVTCORE at IETF 87 and 88:
http://www.ietf.org/proceedings/87/slides/slides-87-avtcore-2.pdf
http://www.ietf.org/proceedings/88/slides/slides-88-avtcore-4.pdf

I had assumed you were at the meetings and saw the presentations, but perhaps not.

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

You'll also note that it evaluates the circuit breaker on several thousand packet traces taken over the public Internet, to residential users in the UK and Finland. It is, of course, always possible to do more measurements, and in different scenarios, but to say that this hasn't been tested on real networks is false.

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

See above. 

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

If you have specific scenarios where you want more evidence, that haven't been tested, then you need to explain those scenarios. 

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

Given the number of caveats and the flexibility in the circuit breaker, it can hardly be claimed to be "rules set in stone". It's a tool, needed to protect the network, that if designed properly will rarely be triggered, since it's protecting against sustained overload only.

Colin





> 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



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