| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Dmitry, Thanks for the feedback. I agree in general with your comments on the first bullet, but there may be different approaches proposed in the future. Thus, this restriction is not necessary IMO. Regarding the third bullet, I agree with the assumption that
if you are in AC_VO – you are LL by default.
But the opposite is not necessarily true. LL traffic could be classified differently, including the use of L4S indication as proposed in 802.11-2023/679, 802.11-2024/384r3, 802.11-2024/0818, and 802.11-2024/399r0. Residential deployments often send
non-managed traffic to AC-BE including low latency/latency-sensitive/non-latency sensitive traffics. Such use cases are important to address. ‘Low Latency traffic is treated as AC_VO traffic, other cases are
TBD’ is confusing. I would suggest something like “Address the case where Low Latency traffic is treated as AC_VO traffic,
other cases are TBD’. Thanks, Lili From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Hi Lily, Jay, Thank you for your questions/suggestions. Just a clarification question(s) – what is the issue with the first and the third bullet? The first one is really to emphasize that because EDCA has distributed nature the solution to improve it needs to be distributed as well. I.e. solution should follow EDCA spirit and not be dependent on centralized
controller. Results in my contribution were obtained from EDCA based sims. Up to May meeting I saw no other contribution on the topic except mine. Moreover, I saw no single contribution which proposed “centralized” method to
improve EDCA. In that regards, why first bullet is restrictive? About 3rd one – as it was explained multiple times in a course of 3 contributions over past year we are taking consciousness decision to limit improvements to AC_VO instead of extending it to other categories.
At the same time we are reasonably assuming that LL traffic will have TID/UP that map the stream into AC_VO, i.e. if you are in AC_VO – you are LL by default. We understand that there might be some issues with properly setting TID/UP values and in some cases
traffic with LL requirement may get incorrectly mapped or certain traffic with LL parameters classified as something else. Precisely for this purpose we have TBD in bullet 3 to further study/work/polish the solution. Dmitry From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Hi Dmitry, I second Lili's suggestion. Thanks Best Regards Jay Yang (杨志杰)
Original From: LiliHervieu <000027d47e67a751-dmarc-request@xxxxxxxxxxxxxxxxx> Date: 2024年07月19日
03:42 Subject: Re: [STDS-802-11-TGBN] Request to run SP Hello Dmitry, Would you consider removing the part of text in red – it is too restrictive at this time. Also, in line with some comments in earlier presentations, the impact on legacy clients should include both throughput and latency (in green). Thanks, Lili From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Hi Alfred, I would like to run the following strawpoll on HiP EDCA in the upcoming PM2 session Do you agree to improve EDCA to reduce tail access delay of Low Latency traffic in multi-BSS dense scenarios
in presence of best effort traffic? •
The solution to improve EDCA is distributed • The impact on legacy device has to be
balanced in terms of throughput and latency •
Low Latency traffic is treated as AC_VO traffic. Other cases are TBD Regards, Dmity 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 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 |