Re: [rtcweb] STUN for keep-alive - RTCP-less applications

Magnus Westerlund <> Wed, 21 September 2011 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD56F21F8A56 for <>; Wed, 21 Sep 2011 01:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.518
X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vW0-B86qKX2E for <>; Wed, 21 Sep 2011 01:17:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E681B21F8A71 for <>; Wed, 21 Sep 2011 01:17:13 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-25-4e799e1d62d7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 79.AE.20773.D1E997E4; Wed, 21 Sep 2011 10:19:41 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 21 Sep 2011 10:19:41 +0200
Message-ID: <>
Date: Wed, 21 Sep 2011 10:19:36 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <092401cc749b$8fd64940$af82dbc0$@com> <> <> <> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications
X-Mailman-Version: 2.1.12
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, 21 Sep 2011 08:17:14 -0000

(as individual)

If I interpret this correctly, you are arguing that an RTCWEB
implementation shall support a remote end-point that doesn't support RTCP.

My question on that topic is:

What about congestion control against these end-points?

I personally have assumed RTCP with reasonable RTCP bandwidth and
minimal interval (not 5 second) being needed to have even medium time
scale (Several RTTs) adaptation.

I see congestion control for media as a MUST have due to the attack
vector that exist in RTCWEB implementations. A Webservice that has
sufficient amount of users visiting it can create additional
PeerConnections beyond what is necessary for the service that is the
front. These additional PeerConnections can be used to create traffic
load over selected paths in the Internet by selecting a good pairs of
peers to establish these overload streams. If there is no congestion
control, or at least isn't reasonably fair sharing it could push large
amount of other traffic out of the way on the paths selected by the
attacker to be targeted.

In addition it is needed to prevent the media quality to be very bad due
to overloading a path by one self. There is still paths that potentially
have issues even with a single G.711 voice stream, such as a GPRS link
to a cellular.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: