From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0365C3CC5E for ; Thu, 7 Apr 2016 14:23:22 -0400 (EDT) X-AuditID: 60721c4b-f79ee6d000006574-b4-5706a59a45b5 Received: from VAADCEX38.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 17.13.25972.A95A6075; Thu, 7 Apr 2016 14:23:22 -0400 (EDT) Received: from VAADCEX37.cable.comcast.com (147.191.103.214) by VAADCEX38.cable.comcast.com (147.191.103.215) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 7 Apr 2016 14:23:21 -0400 Received: from VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0]) by VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0%19]) with mapi id 15.00.1130.005; Thu, 7 Apr 2016 14:23:21 -0400 From: "Livingood, Jason" To: Kelvin Edmison , Dave Taht CC: jb , bloat Thread-Topic: [Bloat] dslreports bufferbloat tests Thread-Index: AQHRj6BHhWYn608GD0W92KDpPoJDEZ98bG2AgAANjACAAJmFmIAATXGAgAEgeIA= Date: Thu, 7 Apr 2016 18:23:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.254] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4787176A4BBA9F41B10B83A9891B2CFD@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsWSUOxpoTtrKVu4wd55shb9v+6zWjy60MZm ce8sjwOzx5z7E9k8ds66y+6x/eIZpgDmKC6blNSczLLUIn27BK6Mg5sSC/ZxVKzqvsfUwPiM rYuRk0NCwERi4YSH7BC2mMSFe+uB4lwcQgJbmCRuNNxiBkkICRxklJjSqwOROMEocfvsJbAE m4CZxN2FV8BsEQEPifuLOsCmMgs4S7w5+IsVxBYWMJRo637AClFjJDHp+FIWCNtP4t66NYxd jBwcLAIqEnvP24CEeQXsJabu3MgKsauHWWLdhwtg8zmBEn1btoDNZwS69PupNUwQu8Qlbj2Z zwTxgYDEkj3nmSFsUYmXj/+B7RUV0JM4+GklK0RcR+Ls9SeMELaBxNal+1ggbEWJX/OuQN2v J3Fj6hQ2kNuYBRwkdqzkhAhrSyxb+JoZ4k5BiZMzn0C1ikscPrKDdQKjzCwkF81CMmkWwqRZ SCbNQjJpASPrKka5ssTElOTcjPzSEgNDveTEpJxUveT83OTE4hIQvYkRlAaKZLx3MK776X6I UYCDUYmHt2sGW7gQa2JZcWXuIUYJDmYlEd5/C4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR0W AaUE0hNLUrNTUwtSi2CyTBycUg2MiT5iMx2fnbi3Me1cjZnv+d/2sbtLZhSelr6mzbJdWlxB c1NXmLXe+qhddi37tnKyrVOxFi1cGt/sr2Ft+EN0p5i3/I/n6xdE/Urcs6Nos01n12XHN3cW 2WabWO2Z3zB58mm+Fz6G5zf1FOkmyfI0la4QrnDWZp8Sv1PPOWaWwDnjjj0+wlFKLMUZiYZa zEXFiQCTw+px/wIAAA== X-Mailman-Approved-At: Fri, 08 Apr 2016 15:29:56 -0400 Subject: Re: [Bloat] dslreports bufferbloat tests X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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 Apr 2016 18:23:23 -0000 Message-ID: <20160407182321.0njVL9dIQRz1TZgyu1ktqrhJfcvHo2qBvNxdWBLZqfg@z> On 4/6/16, 1:08 PM, "Bloat on behalf of Kelvin Edmison" wrote: >I think people focus on packet loss so much because the term is short, >seemingly conveys a lot of info and is easy to measure. > >Given that know how to measure bloat, it strikes me that what is needed >is a short marketing-style tag for bloat that can be put up against the >term "packet loss". The BITAG has discussed this issue and debated whether to take up a work item on it, because it is clear that it is not always the case that more (or any) packet loss is necessarily bad. And Dave Clark and Steve Bauer have done some good analysis basically saying packet loss measurements don=B9t really correlate the broadband quality and more work is needed. My sincere hope is that the new FCC broadband label does not encourage behavior that will lead to a goal of 0% loss, which would quite obviously be bad in many ways from a performance and quality standpoint and run counter to all the good AQM-related work. Jason