From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 1440A21F449; Thu, 11 Sep 2014 09:03:06 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id va2so355469obc.23 for ; Thu, 11 Sep 2014 09:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Wj1JBJPZqUoIeKUiCOs1UR/sCmE7C87IVexsk4f9wTg=; b=sSIpxlc5UmQFKxL4HNgkUzTf93HTN2YPTdyomgY0UEDU/cX5oUkmjaPvNIy7p9Zpx2 Gd8JEvS3i8auAqvOeCj5Hrv3tb48dyppKQC9FJ9Qf1NOtrF/AXYtu/CW8hncM7mgThUW xIsjJuJJRgG7EPO/kFtPk0phMNA+1s/FwD7wd+Xf1ibvWn/eZ0HGP19AAK8F8IWllw9M TY+p+2VKZrVjLJnAg8zhjTHKHPu4MRUgpM46UlMir96bqxNlsJtpu0l9Jg33+UUEVouC /W9g502TdRaqXn/VBuSmKgmFX12+eiYNFVln0vxTnSfEXyGXVH//zi7A3j6TgK78jnUB Pj5w== MIME-Version: 1.0 X-Received: by 10.182.129.230 with SMTP id nz6mr2372088obb.16.1410451385727; Thu, 11 Sep 2014 09:03:05 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Thu, 11 Sep 2014 09:03:05 -0700 (PDT) Date: Thu, 11 Sep 2014 09:03:05 -0700 Message-ID: From: Dave Taht To: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Wes Felter , bloat , "cerowrt-devel@lists.bufferbloat.net" Subject: [Bloat] Fixing bufferbloat: How about an open letter to the web benchmarkers? 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, 11 Sep 2014 16:03:35 -0000 The theme of networks being "engineered for speedtest" has been a common thread in nearly every conversation I've had with ISPs and vendors using every base technology out there, be it dsl, cable, ethernet, or fiber, for the last 4 years. Perhaps, in pursuing better code, and RFCs, and the like, we've been going about fixing bufferbloat the wrong way. If Verizon can petition the FCC to change the definition of broadband... why can't we petition speedtest to *change their test*? Switching to merely reporting the 98th percentile results for ping during an upload or download, instead of the baseline ping, would be a vast improvement on what happens today, and no doubt we could suggest other improvements. What if we could publish an open letter to the benchmark makers such as speedtest, explaining how engineering for their test does *not* make for a better internet? The press fallout from that letter, would improve some user education, regardless if we could get the tests changed or not. Who here would sign? On Wed, Sep 10, 2014 at 2:54 PM, Joel Wir=C4=81mu Pauling wrote: > I have been heavily involved with the UFB (Ultrafast Broadband) PON > deployment here in New Zealand. > > I am not sure how the regulated environment is playing out in Canada > (I am moving there in a month so I guess I will find out). But here > the GPON architecture is METH based and Layer2 only. Providers (RSP's) > are the ones responsible for asking for Handoffer buffer tweaks to the > LFC(local fibre companies; the layer 0-2 outfits-) which have mandated > targets for Latency (at most 4.5ms) accross their PON Access networks > to the Handover port. > > Most of the time this has been to 'fix' Speedtest.net TCP based > results to report whatever Marketed service (100/30 For example) is in > everyones favourite site speedtest.net. > > This has meant at least for the Chorus LFC regions where they use > Alcatel-Lucent 7450's as the handover/aggregation switches we have > deliberately introduced buffer bloat to please the RSP's - who > otherwise get whingy about customers whinging about speedtest not > showing 100/30mbit. Of course user education is 'too hard' .