From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 A7FFA3B29E; Mon, 2 Sep 2024 11:09:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1725289760; x=1725894560; i=moeller0@gmx.de; bh=oLOJP4vtN1zM+Hz+PS1Zs64uvzQJyXDtLAWOPZbcs54=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=j7y0JyhbEQSwgmEsd+86cl05agzhkiMNFj2nHg/+4wsMtXpycMTfTC70uyvnwREN ij1Vx6oMGJSR96Oz54y5AspvUjaqJ2eoDytw/XphAx5NJsG2DRhBSlVEOySaYmGuR 7pmJOB9WhhEhmMJ3ceydiV3bJIDNZjJ17lXyPx8k3ko79JVbXy9buqO/dP67NXE2+ oBA5twF63PxZMQI0X0uhf4rW9DO0wCA7p0ZEm9zVKNguvpO1RLe3i20hFYBa5GWgn W3/7GN5AIhDoKoxrs6/F2xgtjpcQLqEBhZghM2uFEdZ04+bk+rVc+vt8B5prmKzuT wV5WGq0sLamSiS6J/g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MybGX-1rqY3h0Zx7-0148Az; Mon, 02 Sep 2024 17:09:20 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) From: Sebastian Moeller In-Reply-To: <72A40762-6A00-42B2-83AA-5ABD4F02634B@gmail.com> Date: Mon, 2 Sep 2024 17:09:09 +0200 Cc: David Lang , Starlink , bloat , Make-Wifi-fast Content-Transfer-Encoding: quoted-printable Message-Id: References: <20240902042024.8A7E3620054@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <13so850r-s23q-r0sp-0nqp-ss9q2q522542@ynat.uz> <72A40762-6A00-42B2-83AA-5ABD4F02634B@gmail.com> To: Rich Brown X-Mailer: Apple Mail (2.3776.700.51) X-Provags-ID: V03:K1:PsOFix3+Z11OCvMTgqSntn69y8rpdwEDi20VPcEiOeYvO8LoMNi MurjqdD9jpk6p5Wyrpy3hg7Ar5wvpvArCS7WQ/LVDIi60Nh0gCXT07NlKizpDzbBQHsXfrr FHYYFo0fk5LRRHxZPR7OnqJ2RpRXgSKQNoF+aBhZQpb6ATzRYvfzgLZLR2dZvoGXKYqpJVd Ozdh+tdqYCrFKAoKuaM7A== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:unsUrweUj3Q=;T8w7fA777mSkSr0juVV5NrVzHzl /GUvA9bw0hKjHEjP3LAyVW4BBvr7TQa9vWgcIoguwFUy04/vRF4YPPJj50Z3ou5B5P65BJmHV r36l7CZieZLHS5GkscdZphyegquuf/GX+saiPzeOdVPwZfJ8XkFyDGaB0TVWtfSu8zUZDdnVk vH6Djz4M616zjFKU+o0maydKM+f8kqv/S54APmSDjFgj1qqawu62fA4dPQ6bkglXGU8rqb78d MRqRTazDh8RH/3Ram8V/rKaQdNxeeZaJnnSlB++cKvTNx999pqTCQkgXReDmx9/1FpB1dLXon oqhTocegjppwsjfcc4ZENVLADm+dEUN/Og41NMI+gGvaW0rXQcH7Fqa9AQdIMVuiIpJz3mF1A W1y7qmsx5J8rGTz9KZMqPURqYJkyOQzSA0wG15tQq9sPUCG+1a80sA4GVHrsZfw7CmtIVk0Xq /dJ1kp+7Ab99Rda2/8Vaa1BUVbJ9ltrQpkIGPm2w0kHiIPUJh1m5b2rXq/PEq6Xp6DgK7glBD FuYfJowpBbdPcF4wceyhRiB6QGSOPCL+/7kBrI8E1IHzDM492UOYLM0IlUc/ytVK01rskFKos C0kdNdcEhihKqoB6w6HBsSImLF4bhsomW0fW3yry+GbGy0iYaAUM8iLnHkLuorr9GTWiL3WO0 dEs4yxm3xOgh+wJcstdU35d96Yf1TCkyoaaRY5yhKQzt8DIli0BPxs7+a+j1bHleC+x5MLyt+ N4hCWBA7GHc3+70142iy5WcUAIAiZzOhkoh9X64SeSZhQtljFRkeyGbqrzjZJUb9bSNRwcCSn iaKxCWOToYIe97VIeZKJ3UNg== Subject: Re: [Starlink] [Make-wifi-fast] Real-world testing: wifi8 and 802.11 wg X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2024 15:09:25 -0000 @David, did you ever give a talk about this, and if so is that available = somewhere? And if not, maybe you should ;)=20 Regards Sebastian > On 2. Sep 2024, at 17:04, Rich Brown via Make-wifi-fast = wrote: >=20 >=20 > How can this message be flagged as an important "stake in the ground" = re: testing of Wi-Fi for common/useful situations? Thanks, David... >=20 >> On Sep 2, 2024, at 1:05 AM, David Lang via Starlink = wrote: >>=20 >>=20 >> I'll start off by saying that my experience is from practical = in-the-field uses, deploying wifi to support thousands of users in a = conference setting. It's possible that some people are doing the tests I = describe below in their labs, but from the way routers and wifi = standards are advertised and the guides to deploy them are written, it = doesn't seem like they are. >>=20 >> My belief is that most of the tests are done in relatively clean RF = environments where only the devices on the test network exist, and they = can always hear everyone on the network. In such environments, = everything about existing wifi standards and the push for higher = bandwidth channels makes a lot of sense (there are still some latency = problems) >>=20 >> But the world outside the lab is far more complex >>=20 >> you need to simulate a dispursed, congested RF environment. This = includes hidden transmitters (stations A-B-C where B can hear A and C = but A and C cannot hear each other), dealing with weak signals (already = covered), interactions of independent networks on the same channels (a-b = and c-d that cannot talk to each other), legacy equipment on the network = (as slow as 802.11g at least, if not 802.11b to simulate old IoT = devices), and a mix of bulk-transfers (download/uploads), buffered = streaming (constant traffic, but buffered so not super-sentitive to = latency), unbuffered streaming (low bandwidth, but sensitive to = latency), and short, latency sensitive traffic (things that block other = traffic until they are answered, like DNS, http cache checks, http main = pages that they pull lots of other URLs, etc) >>=20 >> test large number of people in a given area (start with an all = wireless office, then move on to classroom density), test not just one = room, but multiple rooms that partially hear each other (the amount of = attenuation or reflection between the rooms needs to vary). The ultimate = density test would be a stadium-type setting where you have rows of = chairs, but not tables and everyone is trying to livestream (or view a = livestream) at once. >>=20 >> Test not just the ultra-wide bandwidth with a single AP in the rooms, = but narrower channels with multiple APs distributed around the rooms. = Test APs positioned high, and set to high power to have large coverage = areas against APs positioned low (signals get absorbed by people, so = channels can be reused at shorter distances) and set to low power = (microcell approach). Test APs overhead with directional antennas so = they cover a small footprint. >>=20 >> Test with different types of walls around/between the rooms, metal = studs and sheetrock of a modern office have very little affect on = signals, stone/brick walls of old buildings (and concrete walls in some = areas of new buildings) absorb the signal, the metal grid in movable air = walls blocks and reflects signals >>=20 >> Remember that these are operating in 'unlicensed' spectrum, and so = you can have other devices operating here as well causing periodic = interference (which could show up as short segments of corruption or = just an increased noise floor). Current wifi standards interpret any = failed signals as a weak signal, so they drop down to a slower = modulation or increasing power in the hope of getting the signal = through. If the problem is actually interference from other devices = (especially other APs that it can't decipher), the result is that all = stations end up yelling slowly to try and get through and the result is = very high levels of noise and no messages getting through. Somehow, the = systems should detect that the noise floor is high and/or that there is = other stuff happening on the network that they can hear, but not = necessarily decipher and switch away from the 'weak signal' mode of = operation (which is appropriate in sparse environments), and instead = work to talk faster and at lower power to try and reduce the overall = interference while still getting their signal through. (it does no good = for one station to be transmitting at 3w while the station it's talking = to is transmitting at 50mw). As far as I know, there is currently no way = for stations to signal what power they are using (and the effective = power would be modified by the antenna system, both transmitted and = received), so this may be that something like 'I'm transmitting at 50% = of my max and I hear you at 30% with noise at 10%' <-> 'I'm transmitting = at 100% of my max and I hear you at 80% woth noise at 30%' could cause = the first station to cut down on it's power until the two are hearing = each other at similar levels (pure speculation here, suggestion for = research ideas) >>=20 >>> How many different tests would it take to give reasonable coverage? >>=20 >> That's hard for me to say, and not every device needs to go through = every test. But when working on a new standard, it needs to go through a = lot of these tests, the most important ones IMHO are how they work with = a high density of users accessing multiple routers which are distributed = so there is overlapping coverage and include a mix of network traffic. >>=20 >> David Lang >> _________________________________ >=20 >=20 > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast