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

[Emil Ivov <[e-mail]>]

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.
>>
>>     This would imply that if the network "usually" has 20% packet loss,
>> then we have no obligation to "protect" it from 20% packet loss...
>
> Yes, but that is a network that has a good-put of less than 80% that is
> not something I would like to operate. A lot of resources down the drain.

I don't think anyone wishes to operate such a network. The point is that 
we all find ourselves in them and when we do, we'd rather be able to 
join that important call and make the best of it (and that best is 
actually sometimes quite acceptable to the user even if it looks 
horrible in wireshark).

After all, networks are there to serve users. Not just to be pretty.

>>> On a best-effort network, a WebRTC "call" is no more worth than a video
>>> stream session, a download of an archive, web-surfing, etc.
>>
>>     Um... No.
>>
>>     The worth of any Internet stream cannot be judged that way.
>>
>>     It is actually quite likely that a WebRTC call is more valuable to
>> the participants than anything else they might do with their connection.
>> It's not our job to second-guess that evaluation.
>>
>>     Further, "best-effort" describes the _network_, not the applications
>> using the network. Thus, "best-effort" is quite orthogonal to "TCP-
>> Friendly".
>>
>>     We _may_ feel an obligation to appear "TCP-Friendly" (I don't.)
>> If so, we should be looking at how to "enforce" reduction of sending
>> rate in the presence of congestion.
>>
>>     "Circuit-breaker" is a bad name for that, IMHO.
>>
>>     Very roughly speaking, a WebRTC application could add 20% FEC bits
>> to compensate for 20% packet loss. This _is_ a step down the road to
>> congestion collapse; but it's not -- of itself -- a _big_ step. Its
>> effect upon competing TCP traffic _is_ substantial (and there may be
>> political considerations saying we have to reduce that effect).
>
> My personal view is that it is fine to be using FEC to make sensible
> audio when encountering packet loss. But, the total bit-rate in such a
> scenario would be that audio+FEC should use less bandwidth than prior to
> the indication that you have 20% packet loss.

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.

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

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.

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

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

Emil

-- 
https://jitsi.org