Its not clear what is the added value of such overdesigned signaling on top of the semi-static signaling covered in Abhi’s document. This creates some inconsistency with the expected AP behavior in these two docs. For example, in this doc there is proposal
to include “expiration time” but on Abhi’s doc there is nothing similar and in the last version I think even baseline Delay Bound was removed. If the sharing AP doesn’t care about which APs to schedule based on long term delay bound info, why include it here
for the short-term signaling ?
Another question: why are all these overdesigned short term signaling needed only for CTDMA and not for CBF/CSR ?
I suggest keeping the design simple and similar to the design of basic UL triggering: a simple long-term signaling of the intervals and a short-term airtime signaling. The former is covered in Abhi’s doc. The latter is already in the spec.
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
|
Hi Klaus,
[Klaus: first, I would like to point out: the reason we can have these questions and discussion is because we add additional information in the ICR. Without additional information the Coordinating AP has
to rely on information which may not be up-to-date, e.g. Polled AP signaled in MAPC negotiations it serves 16 streams with some characteristics]
In addition to what Dibakar wrote below:
In max configuration you may signal AC, time, LLI and TSF. It is very unclear how this going to help polling STA to decide on what actions it should take.
Example: AP1 send ICF saying “I’m polling AC_VO”
AP2 respond back with ICR saying “I want AC_VI (ups, it cannot do that), I need 2 ms of time; I’m currently servicing LLI (what does it mean?) that actually belong to AC_VO (but I have no way of telling you that) and
my TSF for most urgent traffic XXXX.. but, ups, my urgent traffic belong to AC_BE but I have no way of telling you that as well ”
AP3 respond with ICR saying “I want VO – and I can respond VO because ICF indicated VO; I need 2ms of time; I have no LLI; and my TSF ins YYYY, where YYY is “more urgent” than XXX.
[Klaus: Are you trying to say that we should allow TXOP sharing to different AC if these happen to have “urgent” traffic? For example, AP 1 obtains a TXOP for AC VO and AP2 can use it for AC_BE? I sensed
the group does not think this is fair and that is why we have the Primary AC in the ICF and restrict the ICR to the same or higher AC.
How this going to help ?
Another, less convoluted example:
AP2 say “I need VO; I need 1ms of time; I
do not have LLI; my TSF is XXX
AP3 say: “I need VO; I need 1ms of time; I
have LLI; my TSF is YYY” and YYY is “more urgent” than “XXX”.
How this information going to help AP1?
[Klaus: We don’t have a clear definition for LLI in the standard right now. I suggest it will be consistently applied - some streams get to set the LLI bit, some streams do not - even though streams without
LLI may have more urgent packets. The criteria could for example be a combination of latency and packet drop rate requirement and it would make sense to drop a packet that is more urgent but does not have LLI set]
Third example:
AP2 say “I need VO; I need 1ms of time; I
do not have LLI; my TSF is XXX
AP3 say: “I need VO; I need 1ms of time; I
have LLI; my TSF is YYY” and YYY is “more urgent” than “XXX”.
AP1 finishes _current_ TXOP;
AP3 win contention , perform _usual , non-CTDMA TXOP, send its own LLI data.
AP1 plan own TXOP that it is going to share it with AP3; AP1 again grab TXOP and gives APTXOP to AP3 because it thinks AP3 need to send LLI data…
How this can be prevented/avoided with that scheme ?
[Klaus: AP1 does not finish _current_
TXOP, it shares TXOP with AP3 otherwise it would not have sent the ICF to signal its intention to share the TXOP. I guess your concern is about AP2 - right? If sufficient time, AP1 can share the TXOP with AP2 as well. Let’s assume there is not sufficient time
and the TXOP is consumed after AP3 serves (part of) its LLI traffic. Now, let’s assume - using regular contention, AP1 again obtains a TXOP and shares it. AP3 still has LLI traffic that is more urgent than XXX, then AP 3 should again get (part of) the TXOP.
This may happen but AP2 should have a better chance to win contention than AP1 and the likelihood of this happening s reduced with every new contention.
Side question: what exactly “servicing LLI” mean? It mean a) in this shared TXOP I’ll be sending LLI data b) I have LLI stream itself c) my STAs has LLI stream with me d) I plan to send/solicit some LLI data in a next
TXOP.
[Klaus: I would say preferably a) but it is hard to mandate since that would require a pre-planned TXOP that is followed. Therefore b) which I read as I have LLI stream in DL direction or c) I plan to
solicit LLI data in UL direction. c) is less preferable because it does not say anything about the current buffer situation.
Yet another comment on the note that you have :
NOTE—The Time Requested may be set to the time duration of a pre-planned TXOP for an AC that is the same or higher than the primary AC indicated in the ICF (see 9.3.1.22.7 Feedback User Info field, Figure 9-114g—Feedback
Information field if the Feedback Type field is set to 3) and may include both DL and UL transmissions
This a) suggest/advises particular implementation on AP side b) “may be set”…. How this note helps/explains anything if I sent to a value that is NOT pre-planned TXOP ?
[Klaus: In discussions we concluded that it is a best practice to know what your next TXOP is planned to be. This for example avoids situations where a STA always starts a TXOP with maximum duration because
the TXOP has not been planned. This note should give implementers guidance on how to calculate the time requested but is not mandated.
Dmitry
Hi Klaus,
How the expiration time and LLI sigaling work together is not clear to me. It seems redundant.
Regards,
Dibakar
Hi Klaus,
Thanks for sharing the latest revision.
Please see attached for some friendly (and mostly editorial) suggestions.
Best regards,
Gaius
Hi Everyone,
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