From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 1465C3B29E; Mon, 2 Sep 2024 11:04:22 -0400 (EDT) Received: by mail-qt1-x82e.google.com with SMTP id d75a77b69052e-456774a0fe7so23559871cf.0; Mon, 02 Sep 2024 08:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725289461; x=1725894261; darn=lists.bufferbloat.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=8M5pqe/fDnV+Dq+Nvs2ZjLpZ5AMHSR8KPYbxi9lhua0=; b=dx7umQTniSCe/FAhefA3TV3ZSBnbfTs9uoTtbPDLSTMT81nqNK6O/ebfvRd426NAku s9Kf2K32YYegrRkRPr6dmU7MXqSOXthoPnikL+zhz5aU1+z+APEUmCnugR7D8LNSkOao eRQRASHdRoiv9Eo9TI8d+h5G6JjTZxsva5Sg2wcJxiIiHnswdRqqSeQpYQU5aQFny6d1 /8UcgaDeUoVDhvAF2ZRk7KBTU+hjvYIRSktfJROIGc3WSfPeqVozVRpsOhTcioE2mCym 781hAxHJVQrzmAUxj4WPmFXz2x2IDyd0wBQG4AoeTChr2nSg60Gat4hXNxgEqflmjxa9 JJtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725289461; x=1725894261; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8M5pqe/fDnV+Dq+Nvs2ZjLpZ5AMHSR8KPYbxi9lhua0=; b=CDW/hkSBVb+2EKjYLKCxSh9uDdmnv38KR9Ui/UamhaIjgDC7qivoTAGXKK+JRztQoM 6YYlfjScNWMG3++zSeKLHqbrGb/u/hM0Vxuu46db5UyEgyx1c9S8KZ9zPPBJ1UmcVAXr WG4Ri777w3m9OQpCMl9kv7Y35qgTg6HMj/jowIZyUt5fbMBu8lwBa1QFGEWOltmSKe2a 5Wb1D2aQ8KM/FsBNbI+DW9LGZP57Xa44C32WtDtGKOZYnOdlFeq4RHaBntFokwb5ju4U 7zfxUjVC4oq1elLlcTtaxXJtxZC800hnpJ7sT+Pae9yAmZgLAv+CMWD+mzxbKWxuC00d +iQA== X-Forwarded-Encrypted: i=1; AJvYcCV4oF10kCfOovGi/aY5Mh+0qe2sz2XNbMTRvSzLE0BD/2fBMc1l91JjTaTT92q89UL9I4JSGA==@lists.bufferbloat.net, AJvYcCXTVP+6nSLEYDzwmV3nwWgg1qfRcz7uNUOdOZSx3Y1k0spU0JYujX+zVgSHMh89MXWZwReIjb0qaNA=@lists.bufferbloat.net, AJvYcCXiAR0su+kgOX1VnwC6I7tlXSxq6B8kHxW+o/q69p2ziP/9nbDKheVwlkOqiXb0AvLIFRruh73ZSQlsXV6FDEY=@lists.bufferbloat.net X-Gm-Message-State: AOJu0YwIQNRE+Na7ZSqcz4g9CQewXCw5mgCwVVGp03ZCRyC6umhSO6dg TjqMj3iz1IPDG3CdXtB8JloIxv2CY5WCl+/wJ4cfkSlk2tq5ISLU X-Google-Smtp-Source: AGHT+IEyIj6jlk4ynjRAywsk2zORKLH/ceo7L+msCKL3tRLVvqOGWlny5fsueGoHQbVE53PSEd2cyg== X-Received: by 2002:ac8:6f12:0:b0:456:6538:ace7 with SMTP id d75a77b69052e-4567f55c784mr177556831cf.26.1725289460981; Mon, 02 Sep 2024 08:04:20 -0700 (PDT) Received: from smtpclient.apple ([198.55.239.72]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-45682d97716sm40518421cf.85.2024.09.02.08.04.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Sep 2024 08:04:20 -0700 (PDT) From: Rich Brown Message-Id: <72A40762-6A00-42B2-83AA-5ABD4F02634B@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A01905A2-5EF4-4044-BC6E-6161BF9D30F1" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Date: Mon, 2 Sep 2024 11:04:17 -0400 In-Reply-To: <13so850r-s23q-r0sp-0nqp-ss9q2q522542@ynat.uz> Cc: Hal Murray , Starlink , Make-Wifi-fast , bloat To: David Lang References: <20240902042024.8A7E3620054@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <13so850r-s23q-r0sp-0nqp-ss9q2q522542@ynat.uz> X-Mailer: Apple Mail (2.3696.120.41.1.10) Subject: Re: [Starlink] 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:04:22 -0000 --Apple-Mail=_A01905A2-5EF4-4044-BC6E-6161BF9D30F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii How can this message be flagged as an important "stake in the ground" = re: testing of Wi-Fi for common/useful situations? Thanks, David... > 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 > _________________________________ --Apple-Mail=_A01905A2-5EF4-4044-BC6E-6161BF9D30F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
How can this message be flagged as an important "stake = in the ground" re: testing of Wi-Fi for common/useful situations? = Thanks, David...

On Sep 2, 2024, at 1:05 AM, David Lang via = Starlink <starlink@lists.bufferbloat.net> wrote:


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.

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)

But the world outside the lab is = far more complex

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)

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.

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.

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

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)

How many different tests would it = take to give reasonable coverage?

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.

David Lang
_________________________________

= --Apple-Mail=_A01905A2-5EF4-4044-BC6E-6161BF9D30F1--