From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 BA7D63B2A4; Thu, 9 Nov 2023 09:56:35 -0500 (EST) Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-5ab94fc098cso747759a12.1; Thu, 09 Nov 2023 06:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699541794; x=1700146594; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sLeP02AKVBlz7fCHTycUFqgNgwWiYXy+Z4R5FPUnhgc=; b=aOUZFUIKsCoFDZMiocHsPWh73ujxD4DDehZYtDkqmnWOleugFiPwbuj/POgRnHtkHt OESv0FomQkgPV6DneAa45mU1WRCGMyJ2Tl0Sra2DbkQ1kbU8DyLX2YFRn4GLR0Co3eDL qhhMv7yz5t4B1WomDm27ekGfd9YkTmhqOE9KR5S/KkLn5IgvS++2CTwfzmDLYhPnUSFO vaEZZD7oTKC/e7Upi9LPzCpncIN50s+6JzJu0dpIbJ7i7oyx2A7ZXGDk2HqdF8FzYLBi ZzD+0o6uWA2LpoQAnE6jgvUy9n9wzOW19/+9zP/efTb7xs1VTS3M6L9DSnVvah7V500G tOLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699541794; x=1700146594; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sLeP02AKVBlz7fCHTycUFqgNgwWiYXy+Z4R5FPUnhgc=; b=wEtlokkd52DLKWnYfshxWhNQUqxvVTmhfJnim9dRm2PktlKybO1yMu6hUpnV5JkhHk +/t2DPDSaufc1MtkNeNy/t0IbD2R8XaNmtqnMmDz7Hee6TBzjSHRxvWAX2gs2sHDWZvK GT1N3kHfI8vIuguDEzvDFMhr2Q7FVs4a0YQwoTA1EhS57Ax0nr4CCGHoMKUbeCR4l67C pJSJ5y1XZjXMkUYsWdsqiaRHdHN6oGC5V38vRaMftmibMrcFD90tBQBgrogT/JpEeS04 agTHmRyBBI18GH7Yg6ujdJFOfZZycuCnS24i709nJCpLak78F5xDhjbp2NU2qesrcBLv Rujg== X-Gm-Message-State: AOJu0YzqbRhtXG4oD6LR3WXD7ewv1ZadDYeRYv2gpDtzg4URKgLtuoA2 WYGo6WWHjMReKQkBGgTithoElFAc6q69qmjtBXhGpIoIlq4= X-Google-Smtp-Source: AGHT+IE/MHkYzelu1HONgjH7zls1r8b4Nst2DqkaNwv+ofYtks4XEHFRBtINfpPa2NYvMZj2wJ2UTViOJ1/ftRtpO/M= X-Received: by 2002:a05:6a21:9996:b0:17b:129b:1813 with SMTP id ve22-20020a056a21999600b0017b129b1813mr5744363pzb.1.1699541794051; Thu, 09 Nov 2023 06:56:34 -0800 (PST) MIME-Version: 1.0 From: Dave Taht Date: Thu, 9 Nov 2023 09:56:21 -0500 Message-ID: To: =?UTF-8?Q?Network_Neutrality_is_back=21_Let=C2=B4s_make_the_technical_asp?= =?UTF-8?Q?ects_heard_this_time=21?= Cc: Nicholas Weaver , libreqos Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [LibreQoS] The New Zealand broadband report X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2023 14:56:35 -0000 https://comcom.govt.nz/__data/assets/pdf_file/0025/329515/MBNZ-Winter-Repor= t-28-September-2023.pdf While this is evolving to be one of the best of government reports I know of, leveraging samknows rather than ookla, it has a few glaring omissions that I wish someone would address. It does not measure web page load time. This is probably a relative constant across all access technologies, limited only by the closeness of the (latency) to the web serving site(s). It does not break out non-lte, non-5g fixed wireless. I am in touch with multiple companies within NZ that use unlicensed or licensed spectrum such as uber.nz that are quite proud of how competitive they are with fiber. Much of the 5g problem is actually backhaul routing in this report's case. Rural links can also have more latency because of how far away from the central servers they are in the first place, it would be good if future reports did a bit more geo-location to determine how much latency was unavoidable due to the laws of physics. My second biggest kvetch is on figure 16. The differences in latency under load are *directly* correlated to a fixed and overlarge buffer size across all these technologies running at different bandwidths. More speed, at the same buffering =3D less delay. The NetAlyzer research showed this back in 2011 - so if they re-plotted this data in the way described below - they would derive the same result. Sadly the netalyzer project died due to lack of funding and the closest I have to being able to have a historical record of dslreports variant of the same test is via the internet archive. https://web.archive.org/web/20230000000000*/http://www.dslreports.com/speed= test/results/bufferbloat?up=3D1 To pick one of those datasets and try to explain them - https://web.archive.org/web/20180323183459/http://www.dslreports.com/speedt= est/results/bufferbloat?up=3D1 The big blue blobs were the default buffersizes in cable 2018 at those upload speeds. DSL was similar. Fiber historically had saner values for buffering in the first place - but I am seeing bad clusters of 100+ms extra ms at 100Mbit speeds there. dslreports has been dying also, so anything much past 2020 is suspect and even before then, as the site was heavily used by people tuning their SQM/fq_codel/or cake implementations, not representative of the real world, which is worse. The test also cuts off at 4 seconds. This and most speedtests we have today do not include tests that do not complete - which is probably the most important indicator of genuine problems. My biggest kvetch (for decades now) is that none of the tests test up + down + voip or videoconferencing, just sequentially. This is the elephant in the room, the screenshare or upload moment when a home internet gets glitchy, your videoconference freezes or distorts, or your kids scream in frustration at missing their shot in their game. 1 second of induced latency on the upload link makes a web page like slashdot, normally taking 10s, take... wait for it... 4 minutes. This very easily demonstrable to anyone that might disbelieve this.... Despite my advocacy of fancy algorithms like SFQ, fq_codel or cake, the mere adoption across the routers along the edge of a correct FIFO buffersize for the configured bandwidth would help enormously, especially for uploads. We are talking about setting *one* number here correctly for the configured bandwidth. We are not talking about recompiling firmware, either. Just one number, set right. I typically see 1256 packet buffers, where at 10Mbit, not much more than 50 packet buffers is needed. Ideally that gets set in bytes... or replaced with at the very least, SFQ, which has been in linux since 2002. --=20 Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.htm= l Dave T=C3=A4ht CSO, LibreQos