Hi Michael,
Thank for your comments, please see my response below
From: Michail Koundourakis <m.koundou@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, March 13, 2024 6:48 AM
To: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] Agenda time request
Hi Dmitry,
Thank you for sharing this presentation prior to its scheduled presentation, it certainly needs more than 15 minutes read to be digested.
I have some comments which I am sharing here, as question time is limited in the meetings.
- How do you explain that no-repetition gives the best results in the 99th percentile even in the presence of hidden nodes? Maybe the simulation did not
manage to produce collisions between hidden nodes to them significant (or maybe they are not significant for some reason)? Simplistically thinking, if we have only 2 non-AP STAs and they are hidden one to another, the DS is similar to a CTS-to-self which is
not effective, so repetition by the AP should greatly help in such cases.
[Akhmetov, Dmitry] I assure you there are collisions
😊. Last time when I presented first round of simulation results with 50+ STAs per BSS, I got a comment that realistically we do not
have that many number of clients in a BSS that are doing full buffer traffic. So in, for example 1 BSS case I limited myself to a lesser number of clients. The conclusion is – repetition helps, but impact is not significant.
- An non-AP STA can experience a transmit failure due to many different reasons. I think it is important to limits STAs access to using DS, as it can be easily abused
but not result in improvements. E.g. the non-AP STA transmits the PPDU using a PHY rate which does not have sufficient SNR to be received by the AP.
[Akhmetov, Dmitry] I use RTS/CTS as an initial frame exchange in a TXOP, they are transmitted at a very robust rate. Of cause an RTS may fail because of a channel and not because of interference, but within a BSS
I’d assume a RTS failure is mainly because happening due to the collision. I agree that there should be rules to regulate the frequency of using DS. Examples for such rules can be: STA that used DS and succeeded may not use DS for next X ms. Or it may need
more retransmissions before using DS again. These are just examples, we definitely will need to carefully develop them.
- Are you assuming that the non-AP STAs do not know what the LL traffic characteristics are and therefore this is the reason they use EDCA? I would imagine that the
problem you are trying to solve would not have been created if the AP knew the traffic characteristics of the LL traffic and used one of the existing mechanisms available to service the UL (e.g. OFDMA, R-TWT).
[Akhmetov, Dmitry] Even if STA knows LL stream characteristics we should not always assume STA will be triggered in a right time by an AP. EDCA remains the baseline mechanisms for all cases.
- One of the existing features in 802.11, the ability to modify and advertise updated EDCA parameters can be used to mitigate the collisions experienced when the number
of STAs in a BSS increases significantly. This is something I have not seen (in my limited time I have been participating in 802.11) being discussed/promoted, but I think it can be used to avoid/mitigate the collisions issue. It tries to solve the same issue
by applying the opposite technique, basically increases the space of available backoff values so that collisions are reduced.
[Akhmetov, Dmitry] Agree. Issue though still remain. EDCA by default is the source of collisions. You can tune EDCA values (subject to how STAs comply to EDCA parameters update), but the quality/selection of a new
parameters in an open question
- If we were to adopt DS, I think we would need to introduce something to allow differentiating between the different existing LL priorities (AC_VO, AC_VI, a UP which
has been promoted using Intra-Access Category Priority element, etc), otherwise we risk is compromising relevant priorities. A similar issue arises when STAs start experiencing reduced medium time due to other STAs start using the DS – an effect seen in the
DL latency increasing is some simulation scenarios.
[Akhmetov, Dmitry] Agree, we need to develop “rules of engagement for the DS”
- Not directly related to your presentation, but I think we are reaching the point that the APs and the non-AP STAs have a number of opinions to select from to try
and address the latency issue, so we are risking different devices even within the same BSS trying to use a different mechanism at the same time, in a way that the sum result is not positive. Perhaps we need to start thinking about a framework which will use
the capabilities (and maybe preferences) of the devices and some authority/rules which decide which mechanism(s) is(/are) going to be used in order to provide the best results for the user. Is this something you have considered?
[Akhmetov, Dmitry] Yes, we probably should think about that as well, not sure though if IEEE should develop such “coexistence/interoperability rules” for various WiFi techniques… May be WFA can address that.
Kind regards,
Michail
From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Sent: 11 March 2024 23:43
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] Agenda time request
Dear all,
There is a contribution 2126r1
https://mentor.ieee.org/802.11/dcn/23/11-23-2126-01-00bn-low-latency-channel-access-follow-up.pptx
scheduled for presentation tomorrow in PM1 session. The presentation talk about High Priority EDCA.
This presentation is pretty large (30+ slides). Given announcement made by Alfred, the time for each presentation (as well as for Q&A) will be limited , I’d like to ask people interested in low latency, channel access and preemption topics
to review it beforehand.
Dmitry
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Sunday, March 10, 2024 3:41 PM
To: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] Agenda time request
Acked with thanks.
Regards,
AA
On Fri, Mar 8, 2024 at 8:45 AM Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx> wrote:
Hi Alfred,
Please add the following 2 contributions to the MAC queue
11-24-0470-00-00bn-rethinking-latency
11-24-0467-00-00bn-low-latency-channel-access-impact
Dmitry
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe/TGbn Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
|
|
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1