From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C24C23B29D; Wed, 19 Apr 2023 02:36:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1681886183; i=moeller0@gmx.de; bh=89tnijzkVX950TNApqnVvUcz/sOUzfMIbj8U8F3m0cE=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References; b=by8cYQxziSONerXFXcKg/7NOHyPiPXzNCGEsWGVO9SriFl2t195wYbzdWJMBFQJ9P lsr1qHuFBX6M4eKK+N1fS7UiSHDKZHgMPGfeKE3vatmHYlYXRK5MGXcfhIw0/xPjnM 5hkW4wiX4Q6UDbkk/6ibhCFo2EjdZfmFq6DqouNNHkAPPx5xCGvxy3XO/FM4U6unoY F873Z5bhlcCS4tsAULyrqLEsD30+0aHtHQaAXjK9J2oUFjV3ArQ67fczeZ0Lt3K0Md dBgONL2hKc93hoHLW1cz4FLxz10fPA+HFLvUVRx7K3fWm1om+8vTUvUBr/vBrnaDG2 3Ed/3nbCWo0Kw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [127.0.0.1] ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MWics-1prKj1075c-00X1Iv; Wed, 19 Apr 2023 08:36:23 +0200 Date: Wed, 19 Apr 2023 08:36:20 +0200 From: Sebastian Moeller To: Dave Taht , Dave Taht via Bloat , Rpm , libreqos , bloat User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <0988FDEA-65D4-471D-9CE4-8A832013BF13@gmx.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----3M4ZF6PODA6645MKUDRH2LN89WI4C4 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:zwX6JTcJeSTGwynTK2y5LotBWTzf1eGN10kWLUXZH4NiQUwi7lg Y4LM+rznRwiz4U5/MSi10jxpIyR1+hNvEsqfjxyKZvpXHStxOE4vn5ysGyNzCZBa/HK9DYV f5Y4aY35QmYhxNWNLLO1OTFwk6SHAUlafgdxWKBCGyVD/DZAuTGJNydgZuhi6VHoyCaJnge pu1aENJMHM1sgxzQoZ1MQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:72lRW1QNULQ=;qcKN35Ip/MvCW8immFdU03QtMWv TKJ6g/oEIafPSAGhxy54RTmPEnYwG4nrAILqKBFQlKSFX+d/KF+gK21fctWM3ynmg89Zm6IG9 5O0zsBh1B7Mvu3DY209SlXk9XJdMGw5xO0TGJ+OXMcwSiqyH3pBOO1dh4vpvHo8l3d0pKs1Gy IaAIbMkd9v7U8cK1nCww6qxXyO1+DDEoQg/77iOgUeqpOCxsC97XDcImKo6ylbX9sRi5cqqQl Ed+39Sj1Lu6k42pjshCvIsDPL8vbmJ0v3lYA+QIbUSSUEkkt7Zdx8o/5DfYe8Y4d40vCOOJrv 190F8JVPEbQFWrIcigJaHRrPwAyetBJH/6ic5wlhVpdx6x3+wErOpe9F3QfCiUXYuxgorJcA2 K0q7HNdyRZ5ZVDow5tnymFSABYsaJLHMB2/qUrlWzgKs4BRWPCp4Q3Cgeq60Ohqe0DBccy85l 2RTawaHvdHlCoRBf3Rp7qYwD9ngZgUBDDpzdR2GDV6nvZkn8CF1TIet39tCpSqbVnIKDlEPe5 oNGXUcY/L0ulLm2H8IymHNnmjjaHuOBfi25fcLwjDCHhME1olHTGicU5TmLtsBGWAPrprS9pR qWedLwpLqRhMpqiwybNWZ5xda1Jamn2wyLjdA/a7qzeizTw+JS0g1ha2/TCfO8eRkPlRZvbIc K/VmMQLehzMHOO/rum1+86NUZS3AJ38vIN1Lcl0/h105FG3MpxA2HDBRSJoR477kZWE+Hx516 eoSaAB24pOFZJCFNwK0Xj9GeqH+TPqWFT7zBXbH5Vm0Mbf5IGOsdmgCQpJYbp5/5vJXTpeTNj 1EjFHMb3D/e5R6uRYDGbS90k7JHEEovNxvr9+5f6AUQ5Y7t+gDkT+jW4xGQhOiXQzBi+ruyh1 TkihWWAEgf5oFMvl8n6l+TnK+v6btgRzAv3hq4sgib+7gQFL1dORwb+CirbUqIXiWoHe1irRf oZ3wJKlr4fDi/rUwPl11gQcZb5Q= Subject: Re: [Rpm] [Bloat] cloudflare on a roll X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2023 06:36:25 -0000 ------3M4ZF6PODA6645MKUDRH2LN89WI4C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Also this: https://blog=2Ecloudflare=2Ecom/aim-database-for-internet-quality/ A pretty decent article explaining the issue in a very accessible way=2E Nitpicks (in case David Tuber is on this list): A) jitter is important for gaming (if only as it affects the necessary add= ed delay for de-jitter buffers), just think extreme cases like packet reord= ering, so I think the gaing score should include the jitte sub-score=2E B) "You have to make video calls to her clients all day and you sit in the= office farthest away from the wireless access point=2E" Probably "calls to= your clients" instead=2E Also I am a big fan of the cloudflare test including a packetloss test und= er idle conditions=2E This was really helpful in getting enough users to ch= ip in loss data to convince my ISP that they had a severe loss problem (sus= tained packetloss from ~1-10% even under idle conditions like 1AM), which i= n turn resulted in ISP and some not revealed manufacturer going ona deep de= bug session and apparently squelching the issue=2E Sidenotes=2E: A) even at 0=2E8% random loss TCPs struggle to keep utilisation high, and = it takes an ungodly numer of concurrent flows to saturate even a moderate l= ink=2E B) tying into an earlier discussion about monitoring latency/loss along ne= twork paths and the utility of doing so for endusers, I caught my ISPs atte= ntion by posting a series of MTR traces taken at the middle of the night ag= ainst a set of DNS servers (including my ISP's)=2E All showing increased su= stained loss after a single gateway in Hamburg (and no such loss for other = gateways of the same ISP)=2E There had been complaints of reduced download = rates before, but it apparently it was the longitudinal set of traces that = made their NOC take the matter seriously and spring into action=2E Yes, tha= t ISP should have found/fixed the issue pro-actively, but to paraphrase D= =2E Rumsfeld, you go on the internet with the ISP you have, not the one you= want to have=2E=2E=2E=2E Regards Sebastian On 18 April 2023 17:31:44 CEST, Dave Taht via Bloat wrote: >https://blog=2Ecloudflare=2Ecom/making-home-internet-faster/ > > >--=20 >AMA March 31: https://www=2Ebroadband=2Eio/c/broadband-grant-events/dave-= taht >Dave T=C3=A4ht CEO, TekLibre, LLC >_______________________________________________ >Bloat mailing list >Bloat@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/bloat --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------3M4ZF6PODA6645MKUDRH2LN89WI4C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Also this:
https://blog= =2Ecloudflare=2Ecom/aim-database-for-internet-quality/

A pretty = decent article explaining the issue in a very accessible way=2E

Nitp= icks (in case David Tuber is on this list):
A) jitter is important for g= aming (if only as it affects the necessary added delay for de-jitter buffer= s), just think extreme cases like packet reordering, so I think the gaing s= core should include the jitte sub-score=2E
B) "You have to make video ca= lls to her clients all day and you sit in the office farthest away from the= wireless access point=2E" Probably "calls to your clients" instead=2E
<= br>Also I am a big fan of the cloudflare test including a packetloss test u= nder idle conditions=2E This was really helpful in getting enough users to = chip in loss data to convince my ISP that they had a severe loss problem (s= ustained packetloss from ~1-10% even under idle conditions like 1AM), which= in turn resulted in ISP and some not revealed manufacturer going ona deep = debug session and apparently squelching the issue=2E
Sidenotes=2E:
A)= even at 0=2E8% random loss TCPs struggle to keep utilisation high, and it = takes an ungodly numer of concurrent flows to saturate even a moderate link= =2E
B) tying into an earlier discussion about monitoring latency/loss al= ong network paths and the utility of doing so for endusers, I caught my ISP= s attention by posting a series of MTR traces taken at the middle of the ni= ght against a set of DNS servers (including my ISP's)=2E All showing increa= sed sustained loss after a single gateway in Hamburg (and no such loss for = other gateways of the same ISP)=2E There had been complaints of reduced dow= nload rates before, but it apparently it was the longitudinal set of traces= that made their NOC take the matter seriously and spring into action=2E Ye= s, that ISP should have found/fixed the issue pro-actively, but to paraphra= se D=2E Rumsfeld, you go on the internet with the ISP you have, not the one= you want to have=2E=2E=2E=2E

Regards
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Sebastian


On 18 April 2023 17:31:44 CEST, Dave Taht via Bloat <bloat@= lists=2Ebufferbloat=2Enet> wrote:
--
Sent from my Android d= evice with K-9 Mail=2E Please excuse my brevity=2E
------3M4ZF6PODA6645MKUDRH2LN89WI4C4--