From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 BD96D3CB36 for ; Mon, 27 Aug 2018 04:34:52 -0400 (EDT) Received: by mail-ed1-x52b.google.com with SMTP id z27-v6so7561972edb.10 for ; Mon, 27 Aug 2018 01:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VcWNUj+2AQ/ugzU/wI7b6RnQ8qi256Bs5ifskL6v7LA=; b=QIsuRR1PTA0Wxp7pHBtetOah33pf8/agUlWc9nAJ5T0Nv7PDITJeOsV84XMlEYEPNA OtSzGvODSrcQa8ZCcAgCf8cq9o5exOwn7n/U/DA1CwAdH3Nc+OTlFO/bGZdnjf3nU6yR nxXRs5xPR9lr/f/oWpER+zxMGxjkccMyConpU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VcWNUj+2AQ/ugzU/wI7b6RnQ8qi256Bs5ifskL6v7LA=; b=a2ln2A8FziTMT2dDJ2Z6/eukyFhT1bzprJI3rFjDmO2JqMjDQz9/rPhIORfLpe1c+M z68vSlymGYqHO0KvO1pfI/FaLhHGXGCJpA8i+M1kdq18BC45T3z+fX0AcLtTOeKSPREt yGM9TrP+GaYTGrtlA8FUr2Cbd7Isxiv0hSz2Z2ig4k7WcMRSRvTIEFSIOxy5AIkVwhE8 iThFTdjjvl1jbgKR882SeFF0qbFYNrKg3BFdHt5yBVndsXCHM8sR1sBY4Fe87DFS9+cf lPD1VPfa24QJng+OnZLbIWWyov1xfzMK/GFyyhmgLbCA9v8PUe/kNyCSA676jr8ss4mr U6Ug== X-Gm-Message-State: APzg51Ahq4MsW6NwbfH4rH4Ilq7hKdcJYSHkK2NZPSj6buebVLVYLKVq CewGPwy/SVIt1AYceoDbs9Vi6v5adcW1dsn16eXXJA== X-Google-Smtp-Source: ANB0Vdby8EAHb3J72coJtV4WBLdvWfDlZMDTqXZ1HxHBbSxcCtMzjqKwRGmI61C7oVpXm4s4t2eYVgZ5Mb/CGG1sIoQ= X-Received: by 2002:aa7:c699:: with SMTP id n25-v6mr14666753edq.302.1535358891698; Mon, 27 Aug 2018 01:34:51 -0700 (PDT) MIME-Version: 1.0 References: <1535286372.35121837@apps.rackspace.com> <2282D31E-CBEF-4B42-A6A6-4D6394EE0DF7@gmail.com> In-Reply-To: From: Bob McMahon Date: Mon, 27 Aug 2018 01:34:40 -0700 Message-ID: To: chromatix99@gmail.com Cc: dpreed@deepplum.com, bloat-announce@lists.bufferbloat.net, Make-Wifi-fast , cerowrt-devel@lists.bufferbloat.net, bloat Content-Type: multipart/alternative; boundary="00000000000057e3af057466994d" Subject: Re: [Bloat] [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 08:34:52 -0000 --00000000000057e3af057466994d Content-Type: text/plain; charset="UTF-8" Hi Jonathan, I think in 802.11ax the AP can schedule STAs to some extent so it looks like that technique is coming soon. It is a bw tradeoff per the RUs per user. Multi-User Uplink Operation To coordinate uplink MU-MIMO or uplink OFDMA transmissions the AP sends a trigger frame to all users. This frame indicates the number of spatial streams and/or the OFDMA allocations (frequency and RU sizes) of each user. It also contains power control information, such that individual users can increase or reduce their transmitted power, in an effort to equalize the power that the AP receives from all uplink users and improve reception of frames from nodes farther away. The AP also instructs all users when to start and stop transmitting. As Figure 10depicts, the AP sends a multi-user uplink trigger frame that indicates to all users the exact moment at which they all start transmitting, and the exact duration of their frame, to ensure that they all finish transmitting simultaneously as well. Once the AP receives the frames from all users, it sends them back a block ACK to finish the operation. *Figure 10. Coordinating uplink multi-user operation* On Mon, Aug 27, 2018 at 12:52 AM Jonathan Morton wrote: > > On 27 Aug, 2018, at 10:06 am, Bob McMahon > wrote: > > > > How can a centralized device predict the many "end stations'" network > demand in its time scheduling? > > DOCSIS does it by initially giving stations a tiny window into which to > send requests for time, which are granted by the head-end. This introduces > some latency. Further requests for time can be appended to a real > transmission, which helps efficiency slightly. > > Developing from that model, an AP might initially divide time evenly > between stations, allowing them to send single large packets or several > small packets without an explicit request for time - this is good for > latency. Along with that packet, the station could indicate to the AP that > it has a queue of packets waiting, and the AP would take that into account > when producing its next schedule. It would also take into account its own > queue. > > It may be possible to combine TDM with orthogonal coding. Here the AP > monitors the received signal strength of its stations, and instructs them > to change power so as to minimise the difference between them. This > maximises the SNR for each, should two transmit simultaneously. The > tradeoff, of course, is that orthogonal coding permits a reduction in > waiting to transmit, but requires a reduction in data rate during the > transmission. I'm sure other people have better data on that than I do. > > - Jonathan Morton > > --00000000000057e3af057466994d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Jonathan,


I think in 802.11ax th= e AP can schedule STAs to some extent so it looks like that technique is co= ming soon.=C2=A0 It is a bw tradeoff per the RUs per user.

Multi-User Uplink Operation<= /h3>

To coordinate uplink MU-MIM= O or uplink OFDMA transmissions the AP sends a trigger frame to all users. = This frame indicates the number of spatial streams and/or the OFDMA allocat= ions (frequency and RU sizes) of each user. It also contains power control = information, such that individual users can increase or reduce their transm= itted power, in an effort to equalize the power that the AP receives from a= ll uplink users and improve reception of frames from nodes farther away. Th= e AP also instructs all users when to start and stop transmitting. As Figur= e 10depicts, the AP sends a multi-user uplink trigger frame that indicates = to all users the exact moment at which they all start transmitting, and the= exact duration of their frame, to ensure that they all finish transmitting= simultaneously as well. Once the AP receives the frames from all users, it= sends them back a block ACK to finish the operation.

3D""

=C2=A0

Figure 10.=C2=A0Coordin= ating uplink multi-user operation




On Mon, Aug 27, 2018 at 12:52 AM Jo= nathan Morton <chromatix99@gmai= l.com> wrote:
> On 27 Aug= , 2018, at 10:06 am, Bob McMahon <bob.mcmahon@broadcom.com> wrote:
>
> How can a centralized device predict the many "end stations'&= quot; network demand in its time scheduling?

DOCSIS does it by initially giving stations a tiny window into which to sen= d requests for time, which are granted by the head-end.=C2=A0 This introduc= es some latency.=C2=A0 Further requests for time can be appended to a real = transmission, which helps efficiency slightly.

Developing from that model, an AP might initially divide time evenly betwee= n stations, allowing them to send single large packets or several small pac= kets without an explicit request for time - this is good for latency.=C2=A0= Along with that packet, the station could indicate to the AP that it has a= queue of packets waiting, and the AP would take that into account when pro= ducing its next schedule.=C2=A0 It would also take into account its own que= ue.

It may be possible to combine TDM with orthogonal coding.=C2=A0 Here the AP= monitors the received signal strength of its stations, and instructs them = to change power so as to minimise the difference between them.=C2=A0 This m= aximises the SNR for each, should two transmit simultaneously.=C2=A0 The tr= adeoff, of course, is that orthogonal coding permits a reduction in waiting= to transmit, but requires a reduction in data rate during the transmission= .=C2=A0 I'm sure other people have better data on that than I do.

=C2=A0- Jonathan Morton

--00000000000057e3af057466994d--