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

[Emil Ivov <[e-mail]>]

Hey Magnus,

On 09.05.14, 11:53, Magnus Westerlund wrote:
> 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.

Well, not really. They trigger when specific events occur. Whether those 
events are caused by network conditions and whether those network 
conditions actually are "really bad" is often a matter of perspective.

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

Yes, I agree.

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

That's a lot of must-s for something that is largely an implementation 
choice and for which we only have informational documents.

Yes, circuit breakers could probably be worked around by applications 
but I am not sure how trivial this would be, especially in the case of 
WebRTC.

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

Yes I get that. However we already have "consent freshness" and that 
will do the job in a big chunk of the cases that circuit breakers are 
meant to protect. It is not clear to me that CBs would be a clear 
improvement for the remainder of the cases.

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

OK then, if we agree that this needs to be an implementation choice then 
why don't we just inform implementers of that possibility and 
potentially advise the W3C to add API calls to enable their use?

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

I would agree if we actually had a flawless mechanism that would only 
trigger in cases where it absolutely has to. As you have indicated 
yourself: It is very hard to define programmatic rules that always do 
the "Right thing" here

Cheers,
Emil


-- 
https://jitsi.org