Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP

[Magnus Westerlund <[e-mail]>]

Emil Ivov skrev den 2015-04-26 16:15:
> On 24.04.15 14:41, Magnus Westerlund wrote:
>> John Leslie skrev den 2015-04-23 15:47:
>>> Magnus Westerlund <[e-mail]> wrote:
>>>> But we do need mechanism to protect the network. Especially when the
>>>> network doesn't work as intended that do happens from time to time.

>
> You shouldn't consider FEC as something that is only used as a reaction
> to congestion. Audio codecs such as Opus and Silk allow for inband FEC
> and most apps that I am aware of do turn it on unconditionally prior to
> every call.

No, it is put in there in reaction to loss. Some networks produce almost 
no loss, some a bit-more. I think it is totally appropriate to use FEC 
to combat that loss, as long as the total bandwidth control is such that 
it doesn't increase the congestion level, and thus the loss rates.

 From that I draw the conclusion that you need to have bit-rate 
adaptation and in cases where FEC is enabled, then it is the total 
bandwidth usage that counts, i.e. Media + FEC. Thus, if one adds or 
retunes the FEC application to consume more bits, then the media-bits 
needs to be reduced to fit within the available bandwidth.

>
>> In my opinion a circuit breaker that triggers for a sustained packet
>> loss rate of 20% over a time period of seconds, is in fact doing its
>> jobb.
>
> This is where I disagree. In many cases sustained 20% packet loss is
> something that inband FEC would fix.

I am fine that you apply FEC to fix 20% loss, but really sustained 20% 
packet loss means that the network is congested, and the bandwidth 
consumed needs to be reduced, by all parties.

>
> How many users do you think would be happy in such situations when given
> the explanation that: we could have made your call work but it really
> makes us look bad to mess with such crappy networks.

Here I totally disagree with you. If you are self-congesting your 
application, then your own failure to reduce the bit-rate in response to 
the congestion, is what causing the issue. If you are competing with 
other flows, and several has your approach, then you all makes it 
impossible to adjust to a sensible working point. You are helping ensure 
a broken network usage.

As I see it, the browsers/ webRTC endpoints will need to be the 
guardians here. They can't let the JS applications do whatever they want 
to the network.

>
>> If there is a short duration, like 400 ms with that loss rate and
>> then it otherwise drops down below 5% for the next 5 seconds and this
>> flow is in the region of 30-50 kbps in total, then I think that is fine.
>> All based on my judgement. I haven't, but believe that if you run this
>> case through the circuit breaker, you might get away with it. It is the
>> TCP equation based breaker that is the one that will fire here if any.
>> So it depends on the RTT and how many loss events this corresponds with.
>>
>>
>>>
>>>     "Circuit-breaker" is not a terribly effective way to do that --
>>> especially when the WebRTC application can simply start another call.
>>
>> Well, to automatically restart/create a new PC when the circuit breakers
>> has triggered is not in the spirit of things. The spirit of things is to
>> adjust your parameter settings so that it consumes less bandwidth, then
>> start it again, or simply let the session be, unless the human user
>> insists.
>
> Your "spirit of things" does not necessarily coincide with that of the
> application/service providers and users.

But, this comes back to that the network is a shared resource, if you 
missuses it, then it becomes destroyed. This is a Tragedy of the commons 
case.

>
> Also, given that users will be allowed to insist, what exactly have we
> done to resolve congestion?

you are right, the use should not be allowed to insist, if the 
application can't adjust down its bandwidth consumption. If it can 
adjust it down with a significant factor, then I am fine with it 
restarting.

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