From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4FA7821F164 for ; Thu, 7 May 2015 06:18:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 51C90A1; Thu, 7 May 2015 15:18:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1431004731; bh=ZcSgnIFL5d6ju23fyi15Nr8nw6pNfBhNabfw1FumA0g=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WxJuynFLbexDlXuJjbIbPLxlkaEbNKJn6Q0yzxkOhffO45S3syBeri7z1BFhmL9hS p5SknzJtzUl5lvMZYB508NTY2ElLuwwgD8wKXDWlWfrtBabFylZh96/HQ1tmsq30TE 2qXhvZXPbG/Yu/DpsjJHMhtMtB0DA+HcBCNp6dnA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 480FE9F; Thu, 7 May 2015 15:18:51 +0200 (CEST) Date: Thu, 7 May 2015 15:18:51 +0200 (CEST) From: Mikael Abrahamsson To: Jim Gettys In-Reply-To: Message-ID: References: <14ceed3c818.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <0C930D43-A05B-48E2-BC01-792CAA72CAD1@gmx.de> <5549A1B8.50005@superduper.net> <9CF0E173-2CE5-4950-84D1-44EAEF174882@gmx.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bloat Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 13:19:25 -0000 On Thu, 7 May 2015, Jim Gettys wrote: > Ideally, we need to get someone involved in WebRTC to help with this, to > present statistics that may be useful to end users to predict the > behavior of their service. If nothing else, I would really like to be able to expose the realtime application and its network experience, to the user. For the kind of classic PSTNoverIP system I mentioned before, it was usually possible to collect statistics such as: Packet loss (packet was lost completely) Packet re-ordering (packets arrived out of order) Packet PDV buffer miss (packet arrived too late to be played on time) I guess it's possible to get PDV buffer underrun or overrun (depending on how one sees it), if I get a bunch of PDV buffer misses and then I halt play-out to wait for the PDV buffer to fill up, and then I get 200ms worth of packets at once and I don't have 200ms worth of buffer, then I throw away sound due to that... So it's all depending on the whole machinery and how it acts, you need different statistics. How to present this in a useful manner to the user is a very interesting problem, but it would be nice if most VoIP applications at least had a "status window" where these values could be seen in a graph or something similar to "task manager" in windows. -- Mikael Abrahamsson email: swmike@swm.pp.se