From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id DE14021F2A2 for ; Mon, 30 Mar 2015 07:55:05 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so123434113obc.2 for ; Mon, 30 Mar 2015 07:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6TU5UGUozrEDIO7e7ydui3pi/hHxl1FY8N5136XdZXI=; b=nU27OyzrvaDJviFunPXDhOIQmYYmjBFCM/l19IviAeOqOsY9UE63IsdCO56FhzUVPM WKte+LxmQbO82JQvwPqhl8ddNBaWRUrfLfrWYGMHwZEJmDyZMzyZulnkEl/9PrxuJgX9 ZYGG8IJCyMbCxP5Aue2qVnmvTSXr4nHEEnuuRPv9RdCM/Hahhxsjc2jPo45qoVf3eCgZ VNLzGm6TQWxC2wnCizBjmkMo2qFfTlO4KvFcX5lpRQHg7Kyj52GUL7Ie7HudpqOf6ibd u7fRLr0XWacHSsKzMV+xh1l1GpAsV6iYu/QdRXiiksytVqoWcAJL+Fx4E1tVS7X/QUW8 frLQ== MIME-Version: 1.0 X-Received: by 10.60.103.234 with SMTP id fz10mr26909467oeb.11.1427727303688; Mon, 30 Mar 2015 07:55:03 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Mon, 30 Mar 2015 07:55:03 -0700 (PDT) In-Reply-To: References: <20150316203532.05BD21E2@taggart.lackof.org> <123130.1426635142@turing-police.cc.vt.edu> <15A0911A-E3B7-440A-A26B-C5E1489EA98B@viagenie.ca> <1426773234.362612992@apps.rackspace.com> <1426796961.194223197@apps.rackspace.com> <5FD20B4A-A7E8-48C0-89F9-E2EB86DED8A6@gmail.com> <755FC1BE-141C-42FD-B3E3-564488982665@gmail.com> <95B0F8DA-7650-4064-BEE6-F0CDF936D33A@gmail.com> Date: Mon, 30 Mar 2015 07:55:03 -0700 Message-ID: From: Dave Taht To: Pedro Tumusok Content-Type: text/plain; charset=UTF-8 Cc: Jonathan Morton , "dpreed@reed.com" , bloat Subject: Re: [Bloat] Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?) 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: Mon, 30 Mar 2015 14:55:34 -0000 I think the most effective thing would be to add bufferbloat testing infrastructure to the web browsers themselves. There are already plenty of tools for measuring web performance (whyslow for firefox, the successor to chrome web page benchmarker) more or less built in... measuring actual network performance under load is not much of a reach. The issues this would resolve are: 1) speed - the test(s) could use native apis within the browser and thus achieve higher rates of speed than is possible with javascript (and monitor cpu usage) 2) we could rigorously define the tests to have similar features to netperf-wrapper 3) we could get much better tcp statistics as in with TCP_INFO 4) output formats could still be json as we do today, but plotted better 5) ? Problems are: 0) Convincing users to use (and believe) them 1) Suitable server targets for the tests themselves 2) Although the browsers are basically in a nearly quarterly update cycle, it would still take time for the tests to be widely available even if they were ready today 3) Convincing the browser makers that they could use such tests 4) Writing the tests (in C and C++) 5) The outcry at speedtest, et al, for obsoleting their tools (think microsoft vs "stacker") 6) Bloating up the browsers still further