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

[John Leslie <[e-mail]>]

Magnus Westerlund <[e-mail]> wrote:
> 
> Emil Ivov skrev den 2015-04-21 12:10:
>> 
>> I am going to be *very* upset if my browser drops a call because of
>> 10% packet loss. I regularly have calls in hotel networks with up to
>> 20%+ regular packet loss and still enjoy productive conversations
>> thanks to FEC and PLC.
> 
> Yes, with FEC.

   We can take Emil at his word that 10% packet loss does not imply
"crappy audio" to at least some users.

   However, Forward Error Correction _is_ leading us down the path to
congestion collapse: in that the reaction to packet loss is to send
more bits. :^(

   How far down that path is an open question... From my experience,
20% packet loss at MAE-East, for example, was too far.

   But we seem to be talking 10-20% at a hotel choke-point. That's a
different story. The damage is mostly limited to hotel customers.
In all likelihood, the _hotel_ would prefer to punish Emil -- but
that's not _our_ job.

> And I pulled 10% out of hat. I should of course [have]  calculated
> the 10* TCP rate for some typical RTT to determine if the circuit
> breaker would fire or not.

   Packet loss is an easier metric for us to understand.

> But, as you already discussed, the point is that your network usage is
> grossly unfair...

   I doubt folks in Emil's position would agree that 10*TCP is "grossly
unfair". (4*TCP is normal in web-browsing, and IW10 sends a lot more
bits...)

   But perhaps they could agree that 20% packet loss is "too far" down
the road to congestion collapse. (I'm pretty sure they'd agree that
10% packet loss is something the hotel "really-should" fix; and I
suspect we should stay out of that tussle.)

>... I am actually fine with it as long as the implementation does
> have some adaptation mechanism. But, from a specification point of
> view we did need a stop gap. I think the progress in RMCAT is clear
> on that.
> 
> I do note that especially when one adds FEC, one do need adaptation.
> One can't use ones redundancy to steam roll all other flows sharing
> a congested bottleneck.

   My intuition says that 72 kbps goodput must not be guaranteed in
the presence of 20% packet loss -- but that dropping to 0 kbps should
not be the only reduction option.

   YMMV...

--
John Leslie <[e-mail]>