Re: [rtcweb] Review of draft-ietf-rtcweb-rtp-usage

[Colin Perkins <[e-mail]>]

On 8 May 2014, at 17:47, Emil Ivov <[e-mail]> wrote:
> On 08.05.14, 14:54, Colin Perkins wrote:
>> On 8 May 2014, at 13:43, Bernard Aboba <[e-mail]>
>> wrote:
>>>> On May 8, 2014, at 3:45, Colin Perkins <[e-mail]>
>>>> wrote: The fix here is to delete “In the absence of a concrete
>>>> congestion control algorithm, all”, leaving the text as “WebRTC
>>>> implementations MUST implement the RTP circuit breaker…” since as
>>>> you note, we want the circuit breaker even if there is congestion
>>>> control.
>>> 
>>> [BA] The question I have is whether this would be widely
>>> implemented. The Circuit Breaker algorithm pauses sessions, but has
>>> no mechanism to resume them, so it increases brittleness.
>> 
>> The circuit breaker is a mechanism of last resort. If we've designed
>> it correctly, it will only stop sessions that are otherwise unusable.
> 
> Shouldn't we have the "if" cleared before making this a MUST? It is not clear to me that we’ve managed to avoid excessive false positives for example.

The experiments that I, Varun, and Zahed have done look to show the circuit breaker behaving as desired. If you know of scenarios where there are false positives, I’d like to see your data so we can improve the circuit breaker.

>> The resume mechanism is the redial button on the user interface. With
>> a reasonable congestion control algorithm, the circuit breaker should
>> never be triggered.
> 
> This is another part that bothers me with circuit breakers. If there's a reasonable chance that a "redial" would succeed then why did we break the session? If not then why are we encouraging it?

If the circuit breaker triggers then I wouldn’t expect a redial to succeed immediately. Obviously, the longer you wait before redialing, the more likely the network conditions will have changed and the call will succeed. 

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