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

Magnus Westerlund <> Wed, 21 September 2011 12:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C360021F8C51 for <>; Wed, 21 Sep 2011 05:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.52
X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9okMgoi6w7E4 for <>; Wed, 21 Sep 2011 05:15:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AB0D621F8C44 for <>; Wed, 21 Sep 2011 05:15:08 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-3a-4e79d5e0f4cc
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1B.83.02839.0E5D97E4; Wed, 21 Sep 2011 14:17:36 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 21 Sep 2011 14:17:35 +0200
Message-ID: <>
Date: Wed, 21 Sep 2011 14:17:35 +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
To: Hadriel Kaplan <>
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==
Cc: "<>" <>
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 12:15:09 -0000

On 2011-09-21 11:02, Hadriel Kaplan wrote:
> On Sep 21, 2011, at 4:19 AM, Magnus Westerlund wrote:
>> If I interpret this correctly, you are arguing that an RTCWEB 
>> implementation shall support a remote end-point that doesn't
>> support RTCP.
> Yes, although we could make that allowance/exception for audio only -
> in fact, G.711 only if it comes down to it.

Well, I don't know if we can argue that one past the Transport Area
Director? I know I can argue 400 bps as an acceptable non congestion
controlled rate. And that is because that is the equivalent of a full
backed off TCP connection that sends one full Ethernet frame every 30
seconds. We probably can argue 4kbps also as an acceptable rate. But
getting to the next magnitude is more problematic, especially in the
light that there still exist a reasonable large number of access links
around the world that don't have more than a few 10kbps in capacity.

> Ultimately there is no indication in SIP/SDP that an device does not
> support RTCP.  So what would you have the Rtcweb browser do?  Once it
> starts sending media if it doesn't receive RTCP within time X then
> terminate the session automatically?  Would users be ok with that?

I think that must be part of the adaptation/congestion control
algorithm. IF you don't get transport feedback you must stop sending. A
TCP connection that doesn't get ACKs will also not send.

Well, it is a transport failure and you would have to indicate that
connection is lost or something like this.

>> 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.
> If I understand your concern correctly, you're worried about the case
> of a malicious site controlling unsuspecting users as a botnet,
> making calls to each other and flooding the network paths between?


> That can happen anyway: all ends are under control of the malicious
> site, so ICE will succeed... and even if the media layer starts
> throttling itself in a few seconds, the script can just keep
> creating/destroying PeerConnections, feeding new SDP to trigger port
> number changes, etc. And do so for video and audio and data channels
> concurrently or intermixed.

Yes, ICE is not a protection against this. And you are correct that if
you can start at rate higher than your "fair" share and then get
throttled down to the fair rate, then Congestion Control provides less
of a protection against this attack than if you start at or below your
fair share. But, you don't have knowledge about the acceptable rate
prior to actually sending. That combined with the issue of slow starting
media makes it a hard nut to crakc. I don't have really good answer to
the issue and it is clear that some compromise will be reached.


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: