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

Colin Perkins <csp@csperkins.org> Wed, 22 April 2015 22:32 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FFB1B2C3F for <rtcweb@ietfa.amsl.com>; Wed, 22 Apr 2015 15:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adljTJ7v205T for <rtcweb@ietfa.amsl.com>; Wed, 22 Apr 2015 15:32:14 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8221B2CDB for <rtcweb@ietf.org>; Wed, 22 Apr 2015 15:31:54 -0700 (PDT)
Received: from [81.187.2.149] (port=35430 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1Yl3BP-0003GV-C8; Wed, 22 Apr 2015 23:31:52 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A7091E3-8830-4EDE-B4DB-8608F26EE6B7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CAPvvaaLZXH1bFeAVPD=gHUB8egJcemKcCLhtnZrCW3DrdMA9UA@mail.gmail.com>
Date: Wed, 22 Apr 2015 23:31:45 +0100
Message-Id: <B3EC2C3A-3DF1-4AA3-96FC-0C24B5FACDCE@csperkins.org>
References: <CAOJ7v-01DhCKewmC-Cvh4Z-jeOmi=CunisjFWceoPfk2ZM9Wgg@mail.gmail.com> <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <CABkgnnWvU+aYT9zgwEXCUhaO98y9kPyKwHnT=KXSr8O=knfW8w@mail.gmail.com> <CAPvvaa+SNPY+Ait2c8w9GPT-QfP7LEiuU6ejrokba93k60DdVg@mail.gmail.com> <CABkgnnW6KFuJhswLK97LE6J=9vqkf-cmeRMZOuz516ZryeSRQw@mail.gmail.com> <CAPvvaa+wid8y2h0g2040V8bSr50+rQRzpg-tCTK9EUFmtJrZYw@mail.gmail.com> <55361B07.3010707@ericsson.com> <CAPvvaaK-OxXk4=igyqix-XdubRhq+OafYvaTsJhNsbi4KHXJpw@mail.gmail.com> <553627F7.6010407@alvestrand.no> <CAPvvaaLZXH1bFeAVPD=gHUB8egJcemKcCLhtnZrCW3DrdMA9UA@mail.gmail.com>
To: Emil Ivov <emcho@jitsi.org>
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/78YnvEdzMXGBKP514am_R6bj9ac>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Endpoints that don't support RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2015 22:32:16 -0000

On 21 Apr 2015, at 11:53, Emil Ivov <emcho@jitsi.org> wrote:
> Hey Harald,
> 
> On Tuesday, April 21, 2015, Harald Alvestrand <harald@alvestrand.no> wrote:
> Den 21. april 2015 12:10, skrev Emil Ivov:
> > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund
> > <magnus.westerlund@ericsson.com> wrote:
> >> Emil Ivov skrev den 2015-03-30 23:00:
> > So as I've mentioned before, I can see circuit breakers as an useful
> > recommendation for some applications but they are definitely redundant
> > in the context of WebRTC.
> 
> The purpose of circuit breakers is not to save the users from themselves.
> 
> It is to save the network from the users - to make sure that if WebRTC
> users cause persistent congestion in the network, that congestion will
> eventually go away.
> 
> Sure, I completely understand the intention. I just think CBs are a very crude attempt of achieving it. Also somewhat redundant in the context of WebRTC.
> 
> I have repeatedly asked for data that shows how CBs are beneficial in large-scale diverse deployments and so far I haven't seen any (I have even been asked by Colin to provide data that they don't work ... which is quite absurd :) )

The benefit is to the network, not to your application, of course. 

And yes, I am looking for cases where the circuit breaker interferes with real applications, because I want to understand if the circuit breaker is being over-sensitive, or if the applications are being unreasonable.

> This is the same purpose as the AIMD algorithm in TCP (which is not
> particularly beneficial for each individual user).
> 
> Well ... it isn't really the same though is it. AIMD doesn't sadistically kill your connection at the first whiff of trouble ... :) ... it just MDs your bandwidth usage.

If the circuit breaker is working correctly, it won't "kill your connection at the first whiff of trouble". It's designed to stop flows that cause long-term and persistent congestion.

You earlier said:

> I am going to be *very* upset if my browser drops a call because of
> 10% packet loss. I regularly have calls in hotel networks with up to
> 20%+ regular packet loss and still enjoy productive conversations
> thanks to FEC and PLC.

Give us some numbers: what packet size, data rate, and approximate RTT are being used for these calls with 10-20% packet loss, so we can evaluate if the circuit breaker will impact them?



-- 
Colin Perkins
https://csperkins.org/