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

[Emil Ivov <[e-mail]>]

On 08.05.14, 21:02, Colin Perkins wrote:
> 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.

That sounds interesting and I'd actually be happy to see the data 
although I can easily believe that circuit breakers could come in handy 
in certain situations.

draft-ietf-avtcore-rtp-circuit-breakers-05 contains some very useful 
guidelines on determining how and when an application might want to 
consider employing them.

So I am fine with the concept ... *as long as* the choice is left to the 
application.

I don't believe that any of the breakers however have the reliability to 
only trigger in cases where ceasing media transmission is the right 
thing to do. I don't think such a thing is possible given how use cases 
and requirements vary from one application to the next.

> If you know of scenarios where
> there are false positives, I’d like to see your data so we can
> improve the circuit breaker.

It's funny you should ask. I am currently having connectivity issues and 
my media transmissions would every now and then be interrupted for 
periods that go beyond two or three RR packets. I am very happy that my 
sessions just resume when things go back to normal.

In cases like demo stands or some forms of video surveillance, lack of 
media for several (tens) of seconds is not really a problem, whereas a 
break that requires human intervention could be one.

Cases where SFUs decide to selectively NOT forward some RTP but forward 
all RTCP would also trigger false positives, while they are not a 
problem for applications that are aware of their behaviour.

IP layer network mobility à la NEMO, temporary uplink saturation because 
someone mistakenly started a torrent client (and quit a few seconds 
later), someone tripping over a cable and then re-plugging it, buggy NAT 
gateways ... all of those could potentially trigger circuit breakers and 
in all these cases both the application and the user may prefer that 
they don't.

Obviously browsers are a special case but we already have consent 
freshness there and that likely covers most of the concerns for 
undesirable streaming that circuit breakers address.

So again, I feel circuit breakers could be a useful informative 
reference but they can be harmful if REQUIRED.

Emil

-- 
https://jitsi.org