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

[Magnus Westerlund <[e-mail]>]

John Leslie skrev den 2015-04-23 15:47:
> Magnus Westerlund <[e-mail]> wrote:
>>
>> I don't want to argue actual numbers here.
>
>     I'm not wild about arguing numbers, either; but there's no point in
> discussing this at all if we can't discuss numbers.

Sure, my main point was that the numbers I early put out in the thread 
was not intended to definitive in any sense or back up. But, below I 
will give my opinion on numbers given.

>
>> My main point is that WebRTC traffic can be a substantial part of the
>> load on a given congestion point.
>
>     True.
>
>> Fairness is always difficult to discuss, as it is a matter of time
>> scales, traffic importance, user impact and what can actually be
>> done with technologhy being deployed.
>
>     Fairness is _always_ in the eye of the beholder. :^(
>
>> 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.

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

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

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