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

[Magnus Westerlund <[e-mail]>]

Hi,

See inline.

On 2014-05-09 14:12, Emil Ivov wrote:
> 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.
> 

Fair enough. But from my perspective for a real-time interactive
application loss of either forward or reverse path for 10 second or more
is an event that affects the user. And continuing to blast traffic into
such a situation is bad. So either react or let the circuit breaker trip
and shutdown the transmission is for me very reasonable.

When it comes to the TCP equation the fact that the media sender are
going more than 10 times as fast as TCP would do, do indicate that the
send rate is out their into un-fair space. But, sure you can build an
application that works okay with 15% packet loss as long as the delay
isn't going through the roof.

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

But, adaptation to path characteristic aren't trivial. What circuit
breakers offers you are. Either you care about this yourself and do
something better than circuit breakers to avoid tripping it, or you
accept that you have to shutdown when tripping it.

The fundamental statement when it comes to circuit breakers is the
following: We don't want completely unresponsive traffic generators on
the internet. We want the traffic generators to shutdown when they
contribute to cause significant damage.

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

Yes, but circuit breakers are also likely to be adopted/required in
other cases that may not have the consent freshness equivalent. But, I
do agree that consent freshness will prevent one from continuing
peerconnections across path outages that last longer than 30 seconds.

I personally don't see it acceptable to continue to transmit without any
checks even when the packet loss is high but not a complete path loss.

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

When I talk about implementation, I expect the media frameworks and
their RTP stacks in the browsers to implement both circuit breakers and
congestion control, not the javascript applications. Thus, there is no
reason to have a control API. Yes, you need an API to inform the
application about the actual condition so that it can make choices based
on what is available. For example turning off streams in the appropriate
order.

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

TCP is not flawless, nothing in this space is going to be flawless. The
point with the circuit breaker is that it should have low enough risk of
triggering unnecessary and that it also prevent persistent congestion
state in the networks. Based on the simulations for LTE networks that
Zahed presented circuit breakers do allow a media sender to be pretty
bad against others before it acts.

If you have data that it triggers to much, please share. I am not
impressed with hand waving in this matter.

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