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

Emil Ivov <emcho@jitsi.org> Thu, 23 April 2015 05:31 UTC

Return-Path: <emcho@sip-communicator.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 D03341A871D for <rtcweb@ietfa.amsl.com>; Wed, 22 Apr 2015 22:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 2KXJ3qnbV3hu for <rtcweb@ietfa.amsl.com>; Wed, 22 Apr 2015 22:31:57 -0700 (PDT)
Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1621A1B8F for <rtcweb@ietf.org>; Wed, 22 Apr 2015 22:31:55 -0700 (PDT)
Received: by oift201 with SMTP id t201so6064204oif.3 for <rtcweb@ietf.org>; Wed, 22 Apr 2015 22:31:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R8m4xPUgr7hXMMKxVxEWgZU2I5haO4I+4hiMKedyyDw=; b=kzyW5SkBib1PuIxUnIKkA6ziWCKXNQVm6sV/xvd4sDXh0tb5/1ZautF3dsLmEqBYFn nVnwDeHyRhGSDdDhD6E0b2VZDLxOQp3eYuJUBhl34YdX3YlvwWn/B5m7vXix+KmYM+9F psfRRe7u+cY95QoNWQhVp3U8uUi3DpM0UJJNsol85mps3pBt71bUrA67kX9pMCY3maz8 8KBgWRdJ0UqEkgko16JVR3QSoxBgekZ8WTluD6VT1GNohcdOeTGJsGRN2glScsjt7huN cPsg5Lr9thk3guZz0W76OgrWm/0HIPNyUhB9FuTooDdEqDceNw/dMbgcw8/VCdcc7rYZ YqAA==
X-Gm-Message-State: ALoCoQlTiinFdmuvhL8dtKxpOBGhjGXGY3E+oHb4ZOr3hSCOHXU5YACB+OHqxDjz67Yj2S+fpHSi
X-Received: by 10.202.80.22 with SMTP id e22mr890222oib.76.1429767115043; Wed, 22 Apr 2015 22:31:55 -0700 (PDT)
Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com. [209.85.218.50]) by mx.google.com with ESMTPSA id oo10sm4376232oeb.0.2015.04.22.22.31.53 for <rtcweb@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 22:31:54 -0700 (PDT)
Received: by oiko83 with SMTP id o83so6149138oik.1 for <rtcweb@ietf.org>; Wed, 22 Apr 2015 22:31:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.223.228 with SMTP id qx4mr950401oec.24.1429767113454; Wed, 22 Apr 2015 22:31:53 -0700 (PDT)
Received: by 10.76.22.9 with HTTP; Wed, 22 Apr 2015 22:31:53 -0700 (PDT)
In-Reply-To: <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> <B3EC2C3A-3DF1-4AA3-96FC-0C24B5FACDCE@csperkins.org>
Date: Thu, 23 Apr 2015 08:31:53 +0300
Message-ID: <CAPvvaaK+BoLVtK9XKKR4VWkrTw=TsZwd282ZO+RC8y-JeEOvLQ@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
To: Colin Perkins <csp@csperkins.org>
Content-Type: multipart/alternative; boundary="001a1130d02ae8cd9805145d98de"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/sw0USNDsr7TZVGjGdDIdOCH9RWk>
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: Thu, 23 Apr 2015 05:32:00 -0000

Colin,

Is it really that hard to see that the burden of providing
performence evidence lies with the people advocating a solution?

Please show me the data from all the real world deployments where you
evaluated your mechanism and showed that it performed reasonably well!

Emil

On Thursday, April 23, 2015, Colin Perkins <csp@csperkins.org> wrote:

> On 21 Apr 2015, at 11:53, Emil Ivov <emcho@jitsi.org
> <javascript:_e(%7B%7D,'cvml','emcho@jitsi.org');>> wrote:
>
> Hey Harald,
>
> On Tuesday, April 21, 2015, Harald Alvestrand <harald@alvestrand.no
> <javascript:_e(%7B%7D,'cvml','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/
>
>
>
>
>

-- 
--sent from my mobile