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

[Magnus Westerlund <[e-mail]>]

On 2014-05-08 23:48, Emil Ivov wrote:
> 
> 
> 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.

The circuit breakers triggers when the conditions are really bad. I
think the one condition which is most likely to give a false positive is
the loss of feedback, i.e. that one loses all RTCP packets under 3
regular reporting intervals.

It is very hard to define programmatic rules that always do the "Right
thing" here. Because with hindsight you can determine one action more
appropriate than another.

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

Well, the important aspect here is how your sending client behaves
during these outages. The circuit breaker do requires you to have cut
back the transmission in these conditions to less than a 10th of the
nominal rate during these outages if the circuit breaker triggers. That
means that you can continue to send low bit-rate traffic to detect when
the path is restored and ramp up again with your congestion control.
Thus, I don't see circuit breakers preventing a congestion control
algorithm to operate under these conditions and maintain the session. If
the congestion control isn't there that is another question.

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

A SFU must provide consistent RTCP, i.e. RTCP SRs from the SFU must
provide RTCP statistics for what is actually forwarded, not what the SFU
received from the originating RTP sender.

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

Triggering the circuit breakers just requires the sending client to have
taken sufficient action to prevent persistent congestion. If it does it
can continue to transmit.

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

The point of the circuit breakers is to prevent situations where RTP
senders continue to blast away into a persistent congestion situation or
onto paths that are broken.

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

I think they will from a protect the network perspective needs to be
REQUIRED. As I have tried to explain above, there are actions that are
allowed within the circuit breaker specification that allows a sender to
throttle its traffic sufficiently when it detects a path breakage, to
keep monitoring it until it recovers and then resume transmission. But,
if the implementation in the sender does not care to implement such
functionality, the circuit breaker do require them to cease
transmission. But, it do become a implementers choice.

In addition I don't think IETF should publish an RFC for a RTP media
plane that doesn't have some REQUIRED behaviour when it comes to
protecting the network in persistent congestion situations.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------