| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Samat, Yes, I meant “to share the TXOP”
In such case, a polling AP could potentially use the information to determine which of multiple APs to
share the TXOP with. For example, it may decide to share the TXOP with 3 APs with short required duration than 1 AP with a long required duration. At least the AP can account for such information in its decision.
I agree that not everyone may want to implement this. Perhaps a value indicating “unknown” can address such cases? Best regards, Gaius From: Tong Bian <tong.bian@xxxxxxxxxxxxxxxx>
Hi Samat, Gaius Thanks a lot for joining the discussion and share your thoughts >
Not sure how it helps to poll APs, as the ICR is sent by shared AP after polling. I think Gaius means which multiple APs to “share TXOP” >Since we speak about LLT, it is not about the amount of time but it is about ‘how fast” it can be served. -> therefore, the example provided by you does not hold as it is
not proportional scaling. If you have noticed, we’re also preparing a SP about including LL related information in ICR to better help the sharing AP make decisions Regarding the extra complexity, could you help to share how much complexity this will add? I’m wondering from the actual implementation on chips, how much complexity this will
bring by just including an estimate required TXOP duration. Best regards, Tong Panasonic From: Samat Shabdanov <0000490d4a372b74-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Gaius,
Great to hear from you. Regarding your comment.
>In such case, a polling AP could potentially use the information to determine which
of multiple APs to poll. For Not sure how it helps to poll APs, as the ICR is sent by shared AP after polling.
> For example, it may decide to share the TXOP with 3 APs with short, required duration than 1 AP with a long required duration.
I disagree with you. Bkz you assume that in this case the time can be proportionally scale it down to meet the “optimal” allocation. This is the not case bkz the times requested by shared AP represent different traffic needs (AC, delay bound/expiration times) Since we speak about LLT, it is not about the amount of time but it is about ‘how fast” it can be served. -> therefore, the example provided by you does not hold as it is not
proportional scaling. >At least the AP can account for such information in its decision. How ? as said the potential benefits do not outweigh the implementation complexity
Please note that by the implementation complexity here we don’t imply the challenges of how to estimate precisely these values (algorithms, or SW implementation),
We mean the actual HW/FW implementation on chips. It is about pros/cons and as said, we can achieve the same goals with a simpler implementation, The promised benefits of these times do not outweigh the additional increased complexity, at least nobody has provided any proof for us of otherwise. Thank you, samat From: Gaius Yao Huang Wee <yaohuang.wee@xxxxxxxxxxxxxxxx>
Hi Samat, Just adding some thoughts.
>
if the total requested times from the polled APs > the max TXOP duration under consideration, these params are useless.
Regarding complexity, I guess an implementation may not need to calculate precisely. For example, it could set from a predetermined set of duration options, maybe considering its
queue status or knowledge of its traffic flows, etc. Side:
Actually, I’m not certain how the max TXOP duration in the ICF should be used by the polled STA. How would a polled AP respond differently if the max TXOP duration is more or less
than it needs. Also, the max TXOP duration doesn’t really give an indication of how much time a polled AP can expect since the duration may be split among an undetermined number of APs. So I mean max TXOP duration in the ICF probably is not the be all and
end all. Best regards, From: Samat Shabdanov <0000490d4a372b74-dmarc-request@xxxxxxxxxxxxxxxxx>
Hello Tong,
It is Samat from Mediatek.
The motivation for the params in the ICR is understood. Please note that this param is not accurate. if the total requested times from the polled APs > the max TXOP duration under consideration,
these params are useless.
It is a simple decision on pros/cons. And we think that the complexity of implementing does not justify its promised benefit.
We prefer a simple solution based on the TXOP return mechanism that can achieve the same goal . Thank you samat From: Tong Bian <tong.bian@xxxxxxxxxxxxxxxx>
Hi Dibakar,
(Sorry to jump in the discussion suddenly) Regarding your response, you mean the Max TXOP duration in ICF? It’s just some information that the coordinating AP considers to share, right? How much TXOP each polled AP
use is based on themselves. Let’s say coordinating AP is willing to share 2.5ms, but polled AP only needs 500us is not allowed, and it needs to use more than that? For your suggested a and b methods, giving AP3 another allocation after AP2 is not so efficient. Each polled AP is allocated maximum and TXOP return the rest, and repeat for
each polled AP. I think the more efficient way is let each polled AP include the amount they need in ICR, and have more precise TXOP sharing. Thanks for sharing your thoughts, and I’m happy to have more discussions Best regards, Tong From: Das, Dibakar <dibakar.das@xxxxxxxxx>
In your example, what is the value of the time signaled in the ICF then ? Seems like that info is ignored by both shared APs.. Also, AP1 can do any of the following:
From: Klaus Doppler (Nokia) <klaus.doppler@xxxxxxxxx>
Hi Dibakar, Thanks for the comment and good debates. Let’s say the coordinating AP1 is willing to share up to 2.5ms and receives a response from AP2 and AP3 that they would like to get an allocation. AP2 might just need 500us and AP3 2ms. In the current spec, there is no
way for AP2 and AP3 to indicate to AP1 how much they need. Let’s say AP1 allocates 1.25ms to AP3 and then 1.25ms to AP2. So AP3 is short 750us from its needs. Having the Requested Time Allocation in the response frame
helps the coordinating AP to make a proper allocation. I agree with you, there will still be variations due to retransmissions and imprecise knowledge of UL buffer, but the allocation will still improve - especially in cases when we have such an imbalance
on the allocation needs. Br, Klaus 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 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 |