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

Roman Shpount <> Wed, 30 April 2014 23:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F3CF1A0955 for <>; Wed, 30 Apr 2014 16:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l0jfV6v4hZ1i for <>; Wed, 30 Apr 2014 16:01:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5BCBC1A04E8 for <>; Wed, 30 Apr 2014 16:01:29 -0700 (PDT)
Received: by with SMTP id z60so1952373qgd.15 for <>; Wed, 30 Apr 2014 16:01:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lj3p35FjNf6WxI0ZG8WG8QHyGPXStLVTM3px8fs68Ns=; b=BpPwrysY2lt77nEaZzseRihNJRXQoLeFaygmJIZpKjBwKBWxvYV/jGmrErajYGOdhE I4LvxxZttQ97hNuayRD0L3kezODHn0vc40kjHjxGpCZCxEdsKfDNCxYKIEJFN+JD7KUB /gSNWNiN9EADW+nDPngtfZAp5OMxZoY2h92sUZJetfuLavPlXjFpOn7bUvSIUdlsAlfP UaRO/jD/UxSf6mH7tjvYAEqIfk1/dfs/cc8axusx1knm9jrcyf7CI+dHVoKC9JM3NfJ/ iJXHzozJMDKeXY1qjwOdz+D29sIxuvXmfiNuBTGeq+Hq+/5hNHdJpQZZpR0t6/OpGESt a1Fw==
X-Gm-Message-State: ALoCoQlRgamxS1AnsQ+OR8sqVI7SiWFgaSdXNmyIHiXT4WVcA5Am4l7/0eB6yx8fDAM8TD/k76oB
X-Received: by with SMTP id bp1mr9475330qcb.11.1398898887242; Wed, 30 Apr 2014 16:01:27 -0700 (PDT)
Received: from ( []) by with ESMTPSA id g7sm48651399qaf.14.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 16:01:25 -0700 (PDT)
Received: by with SMTP id j107so2661694qga.0 for <>; Wed, 30 Apr 2014 16:01:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id hz5mr6104584qcb.9.1398898884703; Wed, 30 Apr 2014 16:01:24 -0700 (PDT)
Received: by with HTTP; Wed, 30 Apr 2014 16:01:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 30 Apr 2014 19:01:24 -0400
Message-ID: <>
From: Roman Shpount <>
To: "Cullen Jennings (fluffy)" <>
Content-Type: multipart/alternative; boundary="001a11346f6a197c9004f84a87b0"
Cc: "" <>
Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Apr 2014 23:01:33 -0000

On Wed, Apr 30, 2014 at 5:21 PM, Cullen Jennings (fluffy)

> On Apr 23, 2014, at 9:02 AM, Roman Shpount <> 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