From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4F4E33B260 for ; Mon, 28 Nov 2016 10:14:24 -0500 (EST) Received: by mail-wm0-x22b.google.com with SMTP id c184so41488649wmd.0 for ; Mon, 28 Nov 2016 07:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8nX/Na7RxAhisDNo/oVcus+KeDX8FHeNPHiDmRK+5U0=; b=GIvuf3CruxudyR6YHYJxkY6DAi89TmAjFhIPegKQlSptPR58xJ7JlEYcx4xn3TFl9Q LfETw/jVKdXi9GWAqBQ/PJushj64eTTmhzllz/KuDJfINf0EH02WcPt4XxnwYl61K9jx guIaHFZMdxU+HL77cryTQ+S2Vd33/WY2oGE3xLEHeiVBANm+rQ+o5hzDibYBOSJgA6/H 29uMH85105sOrwnGktqLg4YHT9mlCyvVefZJwbqhJ80yJjjdHSHLl8xmk2i67cOukYd3 IDOpEMjLqnIX0m/cgoSAhfAyv6vSq84Zv4SYXafRuTYv4MfbNKMtui6KpHgFi+DqFLn3 6TpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8nX/Na7RxAhisDNo/oVcus+KeDX8FHeNPHiDmRK+5U0=; b=dhOABrCwtKb1XuWBFAn3LxA5wovEVPkKDIvOVFJWrDIiUMuDarUc7vrmqKuvNrXBbp R7Xrgv1lG2RRg2N6jidkIBly9HOMmKIAZDzuTrnDG5OaSEpqsVpEqOBZOU68KJGXlcQi KNp7/jBphqK8Qap/49po6OBIsu+TngimbxoU1N4YheHHgf79x3Bj35EgH002xOoq+ez8 fu4VKJTYF3447zZI2lCkQbhSlFJD6gcVoPfpEnL35WaiMZwtsourKCCvdNivnyuckUur sBpsrki1sUDlrMi/j7fqyJoY/Pvw2mCJ9XjCM2x6sMo/ho0Ia2RgLiqTGSFPB6cZiO2c RsTQ== X-Gm-Message-State: AKaTC00hVUcAbmBCP8UZDgnRELjQ8oaXo0cNbujf9ur6znx0fm+WOEpL4pb/DCpjG75Gj+fTZ9bQxDCbx5m00Q== X-Received: by 10.28.46.144 with SMTP id u138mr18480084wmu.136.1480346063360; Mon, 28 Nov 2016 07:14:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.145.155 with HTTP; Mon, 28 Nov 2016 07:14:22 -0800 (PST) In-Reply-To: References: <548F6875-8670-4784-8A4D-9D4E6F0F20BD@gmail.com> <65cde0ee-4cc8-22c8-5274-a4eafe9cf338@pollere.com> From: Pedro Tumusok Date: Mon, 28 Nov 2016 16:14:22 +0100 Message-ID: To: David Collier-Brown Cc: bloat Content-Type: multipart/alternative; boundary=001a11422ade40597e05425dedb9 Subject: Re: [Bloat] Fixing bufferbloat in 2017 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: Mon, 28 Nov 2016 15:14:24 -0000 --001a11422ade40597e05425dedb9 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 28, 2016 at 1:48 PM, David Collier-Brown wrote: > A short RFC with a clear summary would change the ground on which we stand. > Include me in if you're planning one. > > --dave > > There are some RFCs that vendors uses for throughput testing, RFC2544 I have seen on a few Firewall vendors datasheets atleast, not seen any reference RFC3511. Pedro > > On 28/11/16 01:00 AM, Jan Ceuleers wrote: > >> On 28/11/16 03:16, Jim Gettys wrote: >> >>> Ookla may have made themselves long term irrelevant by their recent >>> behavior. When your customers start funding development of a >>> replacement (as Comcast has), you know they aren't happy. >>> >>> So I don't sweat Ookla: helping out the Comcast test effort is probably >>> the best way to get bufferbloat in front of everyone, and best yet, the >>> code for the tests is out there. >>> >> I do hope you're right Jim, but I still worry that Ookla is heavily >> entrenched in carriers' test labs. This position has, I believe, come >> about not because of Ookla's expertise in network testing but rather >> because of market pull (i.e. speedtest.net's huge popularity with >> end-users). >> >> As long as both of these positions remain (i.e. Ookla's mind share of >> end-users and their resulting market share in the labs of large >> purchasers of CPE) their lack of interest in bufferbloat is going to >> keep this topic off the agenda in a large part of the industry. >> >> Unless Ookla can be coerced somehow. >> >> I have previously suggested standardising network throughput testing >> methods and "grading" criteria. If there's an RFC on this subject >> carriers are going to be interested in conformance to it and will >> pressure their suppliers (of network testing gear, of CPE etc). >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > davecb@spamcop.net | -- Mark Twain > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > -- Best regards / Mvh Jan Pedro Tumusok --001a11422ade40597e05425dedb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 28, 2016 at 1:48 PM, David Collier-Brown = <davec-b@rogers.= com> wrote:
A short RFC wit= h a clear summary would change the ground on which we stand.
Include me in if you're planning one.

--dave

=

There are some RFCs that vendors uses for throughput te= sting, RFC2544 I have seen on a few Firewall vendors datasheets atleast, no= t seen any reference RFC3511.

Pedro

=
=C2=A0

On 28/11/16 01:00 AM, Jan Ceuleers wrote:
On 28/11/16 03:16, Jim Gettys wrote:
Ookla may have made themselves long term irrelevant by their recent
behavior.=C2=A0 When your customers start funding development of a
replacement (as Comcast has), you know they aren't happy.

So I don't sweat Ookla: helping out the Comcast test effort is probably=
the best way to get bufferbloat in front of everyone, and best yet, the
code for the tests is out there.
I do hope you're right Jim, but I still worry that Ookla is heavily
entrenched in carriers' test labs. This position has, I believe, come about not because of Ookla's expertise in network testing but rather because of market pull (i.e. speedtest.net's huge popularity with
end-users).

As long as both of these positions remain (i.e. Ookla's mind share of end-users and their resulting market share in the labs of large
purchasers of CPE) their lack of interest in bufferbloat is going to
keep this topic off the agenda in a large part of the industry.

Unless Ookla can be coerced somehow.

I have previously suggested standardising network throughput testing
methods and "grading" criteria. If there's an RFC on this sub= ject
carriers are going to be interested in conformance to it and will
pressure their suppliers (of network testing gear, of CPE etc).
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


--
David Collier-Brown,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Always do right. Th= is will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net<= /a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark Twain


_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat



--
=
Best rega= rds / Mvh
Jan Pedro Tumusok

--001a11422ade40597e05425dedb9--