Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?

[Roman Shpount <[e-mail]>]

On Wed, Apr 30, 2014 at 5:21 PM, Cullen Jennings (fluffy)
<[e-mail]>wrote:

>
> On Apr 23, 2014, at 9:02 AM, Roman Shpount <[e-mail]> wrote:
>
> > I would say that some video end points have congestion back off.  Almost
> all audio end points have none. Based on this, most UDP endpoints do not
> deal well with congestion.
>
> Well … I sort of agree with you and Wenger and sort of don’t. They have an
> upper layer congestion control. Basically when the congestion gets bad, the
> humans on both ends hang up the call and go call each other on their cell
> phones.


I know we are deep in the discussion but originally I was addressing the
following point:

On 2014-04-23 14:31, Harald Alvestrand wrote:
>  All UDP endpoints that use the open Internet have some form of backoff
on congestion - using delay, packet drop or
> (most likely) both to detect congestion

>From my experience this is not true for almost all voice end points and it
is not true for majority of video end points. So, Harald's assumption does
not hold.

I think based on this assumption Harald was trying to decide if QOS support
needs to be exposed in WebRTC. My second point was that if congestion is
introduced by something other then the real time media client (such as
loading a large document over HTTP from public internet or using a separate
screen sharing program which uses TCP to upload the screen on a slide
change), there is little that can be done by the real time media end point
to deal with this congestion except implement a good packet loss recovery
policy. Better handling of such congestion will require either changes to
router queuing policies (using PIE or Codel queuing policies at the point
of congestion can help a lot) or better yet implementing QOS. Such router
policy changes are outside of this groups charter, but exposing QOS support
to WebRTC is definitely something that should be discussed.
_____________
Roman Shpount