| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Osama, Thanks for the detailed questions. I appreciate you taking the time to review the simulations. Please see my responses in line. Note that the concept of the protected windows shown in the simulations is somewhat independent of the TID discussions, but we used it as one example to show how we can achieve a differentiated service in channel access when we are able
to characterize and prioritize the traffic streams. Thanks Dave From: Osama AboulMagd <Osama.AboulMagd@xxxxxxxxxx> Hi Dave, I have few comments/questions related to 11-20/0418r4. Most of my comments are related to simulations. It is clear that the LL traffic parameters (100 B every 4 ms) and the protected window parameters (1 ms every 5 ms) are chosen to coincide with each other to yield better delay values as shown on slides 25,26,
and 27. I am wondering what will happen if there is a variety of LL traffic with different duty cycle?
[DC] The amount of time allocated to the protected windows would have to be adapted based on the low latency traffic mix and duty cycle. That is why it is important to enable the QoS negotiation including exchange of the traffic profile/requirements.
The AP would have to decide how much time to allocate for the protected windows based on the requirements. Also, it doesn’t necessarily need to have all traffic within a single window. There could be multiple windows (or service periods) for different traffic
streams, depending on the mix. I believe my observation is justified by the results of the second scenario where the protected window duration is 500 ms. The differences between delay results in slide 28 and slide 29 are not as pronounced
as those earlier results (note that you are using different x-axis scale on slide 28 and 29) [DC] one clarification, the protected window size in scenario 2 is reduced to 500 microseconds and channel bandwidth is reduced to 20 MHz in order to create more load on the channel. If you look at the UL results, the worst case latency
is higher without the protected window compared to the earlier results with higher channel capacity. On the other hand, with the protected window, the worst case latency is more or less the same in both scenarios. The main goals was to show that the reserved
time for low latency will protect it from congestion, which is an expected result. Even with the careful selection of parameter values the delay results show that when a wider channel is available the advantage of the so called protected window is diminished (slide 26) and may sometimes disappear
(slide 27). While I understand it is not always possible operating in the 6GHz band with more availability of wider channels may solve the problem without the need to introduce any new mechanism. [DC] This is a good observation and it reflects the fact that when there is enough capacity and no congestion, the latency can be very low already. But the problem that we are trying to solve, for many of the emerging real-time applications,
is the high worst case latency when there is congestion on the channel. This is one of the main gaps in 802.11 w.r.t. to low latency reliable services and also captured in the EHT PAR. For instance, if we add more background traffic in the simulations scenarios
with higher channel bandwidth, the worst case latency will increase without the protected windows. Adding bandwidth helps, but it leaves us with the status quo/gap that Wi-Fi’s latency is always variable and it is not good enough for applications that need
low latency reliable services. I understand you are using EDCA during the protected window. Am I correct? If yes, then what are the EDCA parameters values (e.g. contention window sizes, etc) you are using for the simulation? Are you using
AC_VO parameters? [DC] We used default AC_VO parameters during the protected window. How do you suggest dealing with backward compatibility if TID values are used for a purpose other than identifying traffic streams? [DC] We are aware that some TIDs are used for other purposes in 11ax (14 and 15), and I don’t expect compatibility issues there. Could you clarify what are the areas where you envision potential compatibility issues?
Regards; Osama. From: Cavalcanti, Dave [mailto:dave.cavalcanti@xxxxxxxxx]
Hi Alfred, Liwen, Jeongki, Can you please help add the deferred SP in contribution
418r4 to the MAC agenda? Thanks, Dave To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |