Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-06.txt, A12, monitoring quality

Harald Alvestrand <harald@alvestrand.no> Wed, 02 November 2011 21:21 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7E1F0CCD for <rtcweb@ietfa.amsl.com>; Wed, 2 Nov 2011 14:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxS5vrMU1cVM for <rtcweb@ietfa.amsl.com>; Wed, 2 Nov 2011 14:21:41 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C6E7C1F0CC3 for <rtcweb@ietf.org>; Wed, 2 Nov 2011 14:21:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB46939E12F; Wed, 2 Nov 2011 22:21:30 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aWsscBF71mT; Wed, 2 Nov 2011 22:21:29 +0100 (CET)
Received: from [192.168.244.102] (unknown [207.239.83.130]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3C15C39E089; Wed, 2 Nov 2011 22:21:27 +0100 (CET)
Message-ID: <4EB1B450.5040904@alvestrand.no>
Date: Wed, 02 Nov 2011 14:21:20 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Wolfgang Beck <wolfgang.beck01@googlemail.com>
References: <CAAJUQMjP1aTk6T_angdjt0v6p1FSQPHzjppe1_SRNKBmoHdNJA@mail.gmail.com>
In-Reply-To: <CAAJUQMjP1aTk6T_angdjt0v6p1FSQPHzjppe1_SRNKBmoHdNJA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-06.txt, A12, monitoring quality
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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, 02 Nov 2011 21:21:47 -0000

On 11/02/2011 07:33 AM, Wolfgang Beck wrote:
> Section 5.2, Browser Requirements
> "   A12             The Web API MUST provide means for
>                     informing the web application when high
>                     loss rates occur."
>
> Wouldn't it make sense to have a more general API that provides access
> to RTP/RTCP performance counters? A smart JS client might analyze the
> counters and suggest solutions, like 'fix your fine NAT
> configuration'. Providers like to see that data to detect and fix
> problems, too.
Since this is an application API requirement, this discussion belongs in 
the WEBRTC WG, reply-to: set accordingly.

In the discussions at the TPAC this week, it was felt that counters 
should be provided for things like packet loss. A regularly scheduled 
function that reads the lost-packet counter every few seconds and sends 
an alert when it's increasing "too fast" would then satisfy this 
requirement - a good question may be how quickly it's reasonable for the 
application to be informed that such a condition exists; my feeling is 
that "within a few seconds" is fine, but others may have other opinions.

The editor team has (I believe) taken on the task of coming up with a 
first proposal for such a metrics interface.

                   Harald