| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Chunyu I’d like to share my opinions on your first response to Graham in which you argue that distributed scheduling is better for RTA traffics.
•
I think scheduling delay is not an issue based on you assumptions. AP ‘s decision is a semi-static scheduling and would be valid for many periods (as illustrated in p5
of your proposal). Even if a AP is very slow, the delayed decision would affect only one RTA frame transmission. By the way, I don’t think a AP is so slow that it cannot make scheduling decision in several or tens of milliseconds.
•
Traditional CSMA is a full distributed decision making mechanism which has limited ability for low latency traffic in congested cases. It’s seems to me that same thing
would happened if you introduce another distributed mechanism.
•
When STAs make distributed decision and request for slots, can AP ignore those requests and make a new decision? For example, STA 1 ask for slot 1,2,3,4; STA 2 ask for
slot 5,6, AP find out that UL and DL traffic models are identical. AP decide to assign slots 1,2 to STA1, slots 3 to STA2. Is AP allowed to do that? If yes, there are actually no distributed scheduling but another form of QoS requirements. Regards Boyce 发件人: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
Hi, Graham: Sorry the late replay. Thanks for your questions and sharing your thoughts. See inline. Thanks. Chunyu From: Graham Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
I read with interest your 20/0408 and 20/1045 presentations. Forgive me for coming in late and for not hearing the original presentations and maybe I have not understood the proposal well. I spent
a lot of time in the past on QoS, EDCA, HCCA, Video and Voice. I will start by stating that EDCA has served for over 15 years ? its problem has always been that it is self- policing. I spent some time proving that too many devices simply cheat. Used correctly
it might do better. I also spent much time working with HCCA, which is uses an HC, and it was proved that it worked very well and increased the efficiency and throughput of networks. The requirement for a TSPEC is
often seen as a ‘problem’, but the TSPEC is a way to clearly define the QoS requirement. So , splitting the time into allocated and free is not new.
I want to make sure I understand your proposal. The AP advertises the Slot Duration and number of slots, plus the EDCA parameters that can be used in the “priority slots”. Then STAs request assignments
of slots. The AP then advertises the allocations and timing. Contrast this with HCCA. STAs request allocations based upon a set of parameters that describe their QoS requirements (TSPECs). The AP/HC grants the allocations and advertises the schedule. At
allocated time, AP/HC starts the HCCA TXOP, if no traffic, or ends early, AP/HC releases the medium. AP/HCs can negotiate with overlapping AP/HCs so as not to allocate over each other.
On the face of it, your slotted scheme is very similar to HCCA where the AP/HC grants the allocations and advertises the schedule. I can’t see in your presentation how the STAs request their slots
or the negotiation, but I would assume it is, or could be, very similar to the ADDTS scheme. A major problem for Wi-Fi and QoS is OBSS and I would draw your attention to the work carried out in 11aa. 11ax should have sorted out Spatial Reuse better but in
11aa overlapping APs can exchange their allocations and negotiate if they have to share. This is important in my view. [Chunyu:] there is some similarity as you pointed out. One subtle but critical difference here is that, the scheme enables a STA to compute/request the resources it needs. The scheduling decision takes into account a
more distributed input. The proposed scheme (pEDCA for short) doesn’t attempt to solve all the problem. But we try to improve in a few aspects:
1)
If a STA understands its application well, it can make an attempt to compute the resources (airtime in slots) it needs. It doesn’t necessarily require AP to “promise” requested QoS.
2)
It doesn’t require schedule before transmitting and tolerate mis-calculation in ‘scheduling’. If P-traffic overflows requested slots, it still can be transmitted as regular traffic. Vice versa, if the P-traffic
in an interval completes early, the medium can be auto released to regular traffic. In addition, one thing that helps the design of pEDCA is that, we specifically optimize for the mix of a type of traffic pattern (bursty, periodic) with regular traffic. So for some specific basic questions:
[Chunyu:] Yes, TSPEC can be a template used. I also think that for slot assignment/grant purpose, parameters as specified TSPEC element are not quite directly useful ? they are more like good-to-know (but what I’m gonna do about it …). Information like Mean/Peak data rate might be useful for AP to monitor and policy the over-allocation of slots. This is next level of details we can continue to work on.
[Chunyu:] The design leaves room for extension into an inter-BSS coordination scheme. Overlapping AP can negotiate the P-slot assignment. Might be more efficient to share in a group of P-slots fashion to avoid time being
too fragmented. It certainly requires all STAs including APs understand and comply to the protocol requirement if that’s what you mean by “a controlled manner.”
[Chunyu:] In what aspect? Performance? Flexibility? Design/implementation complexity? If you have specific traffic scenarios / KPIs to compare, we can try using our simulation. Architectural kind of evaluation including practicality, complexity, can be difficult to demo at this point. But I do believe
this is a more practical approach for Wi-Fi technology to satisfy RTA requirement as well as serving regular traffic.
[Chunyu:] in pEDCA, STAs still obey CCA (physical as well as virtual/NAV) rules. STAs are still required to contend the medium even they are member of a P-slot. We don’t want to lose the listen-before-talk principal. AP or the owner of P-slot can use whatever suitable NAV protection as they are doing now. 11ax provides more tools such as trigger-based frame sequences that a non-AP STA can let AP take responsibility of initiating the
txop.
[Chunyu:] in pEDCA, AP can do so as well if AP and the non-AP STA agree to use the trigger-based frame exchange, e.g. but in case not, we count on the protection mechanism described in pEDCA:
I am not a regular 11be attendant so I would be grateful if you could let me know when this will be next discussed. [Chunyu:] no problem, thanks for your interest. We were given 10 mins for Q/A in last Wed (08/26)’s meeting. I can schedule an offline meeting with you, and/or anyone else who are interested in. Thanks Graham From: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
Hi, all: Starting a thread for Q/A for the doc 11-20/1045r3 to cover remaining Q/As. I captured Jay, Mohamed, Liangxiao, and Sharan. Other please also feel free to ask questions here or send me separate emails. Thanks. Chunyu 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
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 |