From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bobcat.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D09803CB37 for ; Sun, 19 Nov 2023 11:58:10 -0500 (EST) Received: from [192.168.1.96] (c-69-181-111-171.hsd1.ca.comcast.net [69.181.111.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bobcat.rjmcmahon.com (Postfix) with ESMTPSA id C27E41B313; Sun, 19 Nov 2023 08:58:09 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com C27E41B313 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1700413089; bh=PL5x6vESg+Ew5faSG0kMgwge5hlFZGxAgLC8/DOf2y8=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=ZEo/uRTj+VVcH9sHNbm9IYp//AQFVFRRhil2ge5aSiMSkmm6ngkOOEMD8z4+/L82u q0dfJ9uuy8/l1CWvL1Tj9oqjUK4TVdmCAkyK675C4PE70n+voYN/dpPCvv1tgsGBkz oEDMH/ZXfZoZHTRUZu7a6w4xLbO17usjDJtZbX4s= In-Reply-To: References: <938D9D45-DADA-4291-BD8A-84E4257CEE49@apple.com> <647406f6-9895-4b53-8cad-2e3183e8d723@3kitty.org> X-Referenced-Uid: 00011ab6567702d5 Thread-Topic: Re: [NNagain] A quick report from the WISPA conference User-Agent: Android X-Is-Generated-Message-Id: true MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----VTF5DE6GQMQZ1HQNDEREV6926UJNYI" Content-Transfer-Encoding: 7bit From: Robert McMahon Date: Sun, 19 Nov 2023 08:57:52 -0800 To: thejoff@mail.com, le berger des photons via Nnagain Message-ID: <48c48f44-c5f6-483d-96bf-1fb9daad0fa4@rjmcmahon.com> Subject: Re: [NNagain] A quick report from the WISPA conference X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2023 16:58:10 -0000 ------VTF5DE6GQMQZ1HQNDEREV6926UJNYI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 A TCP 3WHS may be a better test=2E It's supported in iperf 2=2E =E2=81=A3= A much faster tcp connect() is also a differentiator between wired OSP vs F= WA=2E The TCP_FAST_OPEN (TFO) and the setup aspects of QUIC show that fast = early state exchanges are being engineered in, what I consider, non ideal m= anners=2E These setup optimizations remind of the PSTN and circuit setups= =2E It seems best the make them low cost and high speed=2E Not testing tc= p connect() in a robust manner seems a fundamental industry escape=2E Bob= On Nov 19, 2023, 3:04 AM, at 3:04 AM, le berger des photons via Nnagain <= nnagain@lists=2Ebufferbloat=2Enet> wrote: >but you can see if it's doing wh= at you want it to and you can compare >it to >other products in the same sp= ace=2E > >On Fri, Nov 17, 2023 at 9:31=E2=80=AFPM Jack Haverty via Nnagain = < >nnagain@lists=2Ebufferbloat=2Enet> wrote: > >> On 11/17/23 11:27, Dave T= aht via Nnagain wrote: >> >> one of the things we really wished existed was= a standardized way to >> test latency and throughput to routers=2E It woul= d be super helpful if >> there was a standard in consumer routers that allo= wed users to both >ping >> and fetch 0kB fils from their routers, and also= run download/upload >> tests=2E >> >> >> Back when I was involved in opera= ting a network, we tried to track >latency >> and throughput by standard pi= ng and related tests=2E We discovered >that, in >> addition to the network= conditions, the results were often dependent >on the >> particular equipme= nt and software involved at the time=2E Some >companies >> treated ping t= raffic (e=2Eg=2E, anything directed to the "echo" port) as >low >> priority= since it was obviously (to them) less important than any >other >> traffic= =2E Others treated such traffic as high priority - it made >their >> resu= lts in review articles look better=2E >> >> In another case we discovered o= ne brand of desktop computer was >achieved >> much higher throughputs over = the net than similar products from other >> manufacturers=2E It took some = serious technical investigation but we >> eventually discovered that the hi= gh throughput was achieved by >violating >> the Ethernet specification=2E = The offending vendor didn't follow the >rules >> about timing=2E But thei= r test results looked much better than the >> competition=2E >> >> IMHO the= root of the problem is that you can not assume much about >what >> any sof= tware and hardware are doing=2E There are lots of specs, >standards, >> an= d mandates in RFCs or even governmental rules and regulations=2E But >> la= cking any kind of testing or certification, it's difficult to tell >if >> t= hose "standards" are actually being followed=2E If someone, technical >> o= rganization or government regulator, declares or legislates some >protocol,= >> algorithm, or behavior to be a required "standard", it should be >> acc= ompanied by mechanisms and processes for testing to verify that >the >> sta= ndard is implemented correctly and is actually used, and >certification >> = so that purchasers are informed=2E >> >> Jack Haverty >> __________________= _____________________________ >> Nnagain mailing list >> Nnagain@lists=2Ebu= fferbloat=2Enet >> https://lists=2Ebufferbloat=2Enet/listinfo/nnagain >> > = > >------------------------------------------------------------------------= > >_______________________________________________ >Nnagain mailing list >= Nnagain@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listin= fo/nnagain ------VTF5DE6GQMQZ1HQNDEREV6926UJNYI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
A TCP 3WHS m= ay be a better test=2E It's supported in iperf 2=2E

A much faster tcp connect() is also a diffe= rentiator between wired OSP vs FWA=2E The TCP_FAST_OPEN (TFO) and the setup= aspects of QUIC show that fast early state exchanges are being engineered = in, what I consider, non ideal manners=2E These setup optimizations remind = of the PSTN and circuit setups=2E It seems best the make them low cost and = high speed=2E

Not testing tcp connect() in a robust manner seems a fundam= ental industry escape=2E

Bob
On Nov 19, 2023, at 3:04 AM, le berger des photons via Nnagain = <= nnagain@lists=2Ebufferbloat=2Enet> wrote:
but you can see if it'= s doing what you want it to and you can compare it to other products in the= same space=2E

On Fri, Nov 17, 2023 at 9:31=E2=80=AFPM Jack Haverty = via Nnagain <nnagai= n@lists=2Ebufferbloat=2Enet> wrote:
On 11/17/23 11:27= , Dave Taht via Nnagain wrote:
one of the things we really wished existed was a standardized way to te= st latency and throughput to routers=2E It would be super helpful if there= was a standard in consumer routers that allowed users to both ping and fe= tch 0kB fils from their routers, and also run download/upload tests=2E

Back when I was involved in operating a ne= twork, we tried to track latency and throughput by standard ping and relate= d tests=2E  We discovered that, in addition to the network conditions,= the results were often dependent on the particular equipment and software = involved at the time=2E   Some companies treated ping traffic (e= =2Eg=2E, anything directed to the "echo" port) as low priority since it was= obviously (to them) less important than any other traffic=2E   O= thers treated such traffic as high priority - it made their results in revi= ew articles look better=2E 

In another case we di= scovered one brand of desktop computer was achieved much higher throughputs= over the net than similar products from other manufacturers=2E  It to= ok some serious technical investigation but we eventually discovered that t= he high throughput was achieved by violating the Ethernet specification=2E&= nbsp;  The offending vendor didn't follow the rules about timing=2E&nb= sp; But their test results looked much better than the competition=2E
IMHO the root of the problem is that you can not assume much= about what any software and hardware are doing=2E  There are lots of = specs, standards, and mandates in RFCs or even governmental rules and regul= ations=2E  But lacking any kind of testing or certification, it's diff= icult to tell if those "standards" are actually being followed=2E  If = someone, technical organization or government regulator, declares or legisl= ates some protocol, algorithm, or behavior to be a required "standard", it = should be accompanied by mechanisms and processes for testing to verify tha= t the standard is implemented correctly and is actually used, and certifica= tion so that purchasers are informed=2E

Jack Haverty =
_______________________________________________
N= nagain mailing list
Nnagain@lists=2Ebufferbloat=2Enet
https://lists=2Ebufferbloat=2Enet/listinfo/nnagain = 

Nnagain mailing list=

Nnagain@lists=2Ebufferbloat=2Enet
https://lists=2Ebufferbloat=2Enet/listinfo/nna=
gain
------VTF5DE6GQMQZ1HQNDEREV6926UJNYI--