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

[John Leslie <[e-mail]>]

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.

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

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

   "Circuit-breaker" is not a terribly effective way to do that --
especially when the WebRTC application can simply start another call.

> The goal must be to have as much flexibility to offer the media 
> communication at the best possible quality that is supported by the 
> network.

   Reasonable...

   (Gotta run: the IESG telechat starts soon.)

--
John Leslie <[e-mail]>