Hello Matt,
I think you make a reasonable argument, and I've checked with the
commenter and he agrees.
So I propose to resolve CID 2187 as follows:
REJECTED
In the case of reaching
backoff = 0, if a STA for some reason does NOT initiate a transmission, then it should always instead do a new
backoff.
If this is not done, then the STA is left with the condition that whenever the medium next becomes free, then:
a) it will have permission to initiate that suspended transmission.
b) any number of other STAs might have reached the same condition in the meantime because they had the same event occur while this STA was waiting for a free medium
The result is that multiple STA all can initiate at exactly the same time - that is, if the gating condition is the end of some activity on the air, then all of the waiting STAs will see that same gating condition
at the same time.
And all of them will then start a suspended transmission at the same time. I.e. this
behavior will cause an alignment of their states which, absent this condition, would have been randomly aligned states.
E.g. if five STA are waiting to transmit with different
backoff values then as long as the primary is idle, they all count
backoff
and each reaches ZERO at a different time, yet each chooses to not transmit because when it reaches 0, it sees a busy on some secondary
Then, at some point, that secondary becomes IDLE and then all five STAs come blasting out at the same time.
So whenever a
backoff=0 is not used and there is a non-empty TX queue, then a new
backoff should be invoked.
However, we still have a problem, because 10.23.2.4 only allows
"Invoke the
backoff procedure due to an internal collision."
not
"Invoke the
backoff procedure because you could but chose not to transmit."
So some changes are going to be necessary in 10.23.2.4 anyway.
Is there agreement that in the "could but chose not to transmit"
case the
backoff does not change CW[AC] (i.e. not doubled, not reset),
since it is neither failure nor success?
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution
Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From:
Matthew Fischer <matthew.fischer@xxxxxxxxxxxx>
Sent: Monday, 29 August 2022 23:33
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D1.0 CIDs 1985, 1986, 1535, 1419, 2187, 1536 ("STA is permitted to begin a TXOP" and "STA shall perform exactly one of the following actions" and "each EDCAF shall perform one and only one of the following actions")
Mark,
Thanks.
I finally found that definition that you cite.
I see that this definition matches the language that is being replaced by TXOP, so ok, sort of.
That is, I can see the logical equivalence of "initiate frame exchange" with TXOP, so the substitution seems ok, but I do not like this definition of TXOP.
I.e. the definition looks like a moment in time, but there are things like TXOP duration and TXOP limit.
The definition claims to be more than a moment, as in "interval" but then the definition sounds like someone can initiate frame exchanges at any time within a TXOP, but that's not true.
There are limitations. But maybe the definition does not need to mention that, so I probably don't care too much about it.
BUT
I still question the other change:
Specifically, in the case of reaching backoff = 0, if a STA for some reason does NOT initiate a transmission, then it should always instead do a new backoff.
If this is not done, then the STA is left with the condition that whenever the medium next becomes free, then:
a) it will have permission to initiate that suspended transmission.
b) any number of other STAs might have reached the same condition in the meantime because they had the same event occur while this STA was waiting for a free medium
The result is that multiple STA all can initiate at exactly the same time - that is, if the gating condition is the end of some activity on the air, then all of the waiting STAs will see that same gating condition
at the same time.
And all of them will then start a suspended transmission at the same time. I.e. this behavior will cause an alignment of their states which, absent this condition, would have been randomly aligned states.
E.g. if five STA are waiting to transmit with different backoff values then as long as the primary is idle, they all count backoff
and each reaches ZERO at a different time, yet each chooses to not transmit because when it reaches 0, it sees a busy on some secondary
Then, at some point, that secondary becomes IDLE and then all five STAs come blasting out at the same time.
I.e. the proposed language does create a spoiled party
This is why I believe that whenever a backoff=0 is not used and there is a non-empty TX queue, then a new backoff should be invoked.
Note that if the TX queue is empty, and backoff = 0, then no new backoff is needed because the gating event for transmission initiation is not a common network event.
I.e. the gating event for transmission in this case is the entry of a new item into an empty TX queue at a single STA and that is a random event observed by only that one STA.
Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office
On Sun, Aug 28, 2022 at 7:59 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Hello Matt,
Thanks for the review.
> I do not think that we really have a decent formal definition of a TXOP, which is of course, a bit strange, because we have tons of normative text that includes the term TXOP.
You had me worried for a while! But we do have a definition in 3.2:
transmission opportunity (TXOP): An interval of time during which a particular quality-of-service (QoS)
station (STA) has the right to initiate frame exchange sequences onto the wireless medium (WM).
This accords with my understanding of what a TXOP is, so in response
to the rest of your post:
> "Initiate a TXOP" is assertive, in that the action will be to begin a TXOP.
> However, if the initial frame of the exchange is for example, an RTS for which no CTS is received, then while an initiating frame is transmitted, I believe that a TXOP is not actually initiated.
No, I think you had the right to initiate a frame exchange sequence (FES)
and did so by sending the RTS. So the TXOP was initiated.
> But maybe it depends on what the definition of a TXOP is, e.g. is the transmission of just an RTS considered to be a TXOP?
Yes, it is.
> I do not think that we really have a decent formal definition of a TXOP, which is of course, a bit strange, because we have tons of normative text that includes the term TXOP.
> The best that I can find is that an EDCA TXOP is something that is obtained by "winning an instance of EDCA contention".
> So do you win the contention when you reach zero in your backoff counter? Or do you win when you have established that no one else has also reached zero at the same time?
I.e. if you reach zero and transmit an RTS, but do not receive a CTS because some other STA also transmitted an RTS and did receive a CTS, then isn't that other STA the winner of the EDCA contention and you are not a winner?
Per 10.23.2.4 in D1.3 you win when:
— There is a frame available for transmission at that EDCAF, and
— The backoff counter for that EDCAF has a value of 0, and
— (#109)Initiation of a frame exchange sequence is not allowed to commence at this time for an
EDCAF of higher UP.
at which point you can put a frame on the WM (e.g. an RTS).
If you don't get a CTS back, then your TXOP ends, so you won
only to lose shortly thereafter.
> In that case, transmitting an RTS and not receiving a CTS is NOT the initiation of a TXOP.
> Unless.....
> Unless you decide the "initiation of a TXOP" is in itself, a particular action.
> I.e. initiation of a TXOP might be defined as the attempt to win a TXOP by transmitting the initial frame of an exchange.
> In which case, you do not need to actually have a TXOP, but simply transmit in an attempt to get one.
I think this is over-complicating things. Per the definition, you initiate
the TXOP by putting the first frame of a FES on the medium (when you are
allowed to do so, of course).
> Now, one can argue that "initiate a transmission sequence" might also have a similar problem.
> Maybe, but the term "a transmission sequence" could be interpreted to include just an RTS transmission.
I think/hope that now with Graham's changes we consistently talk of frame exchange
sequences, being:
frame exchange sequence: A sequence of frames that maintains control of the wireless medium.
But yes, "initiate a transmission sequence", like "initiate a TXOP", is
what happens when you put an RTS on the air when you win the contention.
> A more important concern is that the deletion of
> "restart the channel access attempt ... "
> There are situations when the choice upon reaching zero backoff is to not transmit when a frame is in the queue, but instead, perform a new backoff.
> Without this text, it is not clear that other text exists that would allow that restart for those situations.
I think this is what CID 2187 is about. This is arguing that if
you had the right to initiate a TXOP, but chose not to, i.e. you
didn't put anything on the medium, you haven't spoiled the party
for any other STA (from everyone else's perspective it's as if you
had nothing to send). So there's no reason for you to backoff at
this point. You get another chance in a slot's time (assuming
someone doesn't get in before you, i.e. transmits in this slot).
> This subclause contains the low level definition of the EDCAF and without allowance for a restart, those other subclauses which call for a restart would contradict the EDACF allowed behavior.
Yes, that's why the proposal is to replace
Restart the channel access attempt by invoking the backoff procedure as specified in 10.23.2 (HCF contention based channel access (EDCA)) as though the medium is busy on the primary channel as indicated by either physical or virtual CS and the backoff counter has a value of 0.
with
Transmit nothing.
in those other subclauses.
(Well, there are other reasons: 1) the current wording is unclear
(invoking the backoff procedure on which EDCAF, specifically?) and
2) the current wording suggests that you backoff if the medium is
busy and the backoff counter is 0, but that's not true: in that
situation you just sit tight, transmitting nothing and leaving
your backoff counter at 0.)
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Matthew Fischer <matthew.fischer@xxxxxxxxxxxx>
Sent: Friday, 26 August 2022 22:37
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D1.0 CIDs 1985, 1986, 1535, 1419, 2187, 1536 ("STA is permitted to begin a TXOP" and "STA shall perform exactly one of the following actions" and "each EDCAF shall perform one and only one of the following actions")
Mark,
In your proposed changes for 10.23.2.4, you are proposing to replace "initiate the transmission of a frame exchange sequence" with "initiate a TXOP"
I'm trying to decide if I find this change acceptable.
I understand your motivation for the proposed change.
Here is a possible reason for not making the change:
"Initiate a TXOP" is assertive, in that the action will be to begin a TXOP.
However, if the initial frame of the exchange is for example, an RTS for which no CTS is received, then while an initiating frame is transmitted, I believe that a TXOP is not actually initiated.
But maybe it depends on what the definition of a TXOP is, e.g. is the transmission of just an RTS considered to be a TXOP?
I do not think that we really have a decent formal definition of a TXOP, which is of course, a bit strange, because we have tons of normative text that includes the term TXOP.
The best that I can find is that an EDCA TXOP is something that is obtained by "winning an instance of EDCA contention".
So do you win the contention when you reach zero in your backoff counter? Or do you win when you have established that no one else has also reached zero at the same time?
I.e. if you reach zero and transmit an RTS, but do not receive a CTS because some other STA also transmitted an RTS and did receive a CTS, then isn't that other STA the winner of the EDCA contention and you are not a winner?
In that case, transmitting an RTS and not receiving a CTS is NOT the initiation of a TXOP.
Unless.....
Unless you decide the "initiation of a TXOP" is in itself, a particular action.
I.e. initiation of a TXOP might be defined as the attempt to win a TXOP by transmitting the initial frame of an exchange.
In which case, you do not need to actually have a TXOP, but simply transmit in an attempt to get one.
Now, one can argue that "initiate a transmission sequence" might also have a similar problem.
Maybe, but the term "a transmission sequence" could be interpreted to include just an RTS transmission.
A more important concern is that the deletion of
"restart the channel access attempt ... "
There are situations when the choice upon reaching zero backoff is to not transmit when a frame is in the queue, but instead, perform a new backoff.
Without this text, it is not clear that other text exists that would allow that restart for those situations.
This subclause contains the low level definition of the EDCAF and without allowance for a restart, those other subclauses which call for a restart would contradict the EDACF allowed behavior.
Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office
On Fri, Aug 26, 2022 at 12:39 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Please note the proposed resolutions to CIDs 1985, 1986, 1535, 1419,
2187, 1536 in 22/0353, which related to the possible actions when
"a STA permitted to begin a TXOP" and "STA shall perform exactly one
of the following actions" (Subclauses 10.23.2.5/6/13/14) in relation
to "each EDCAF shall make a determination to perform one and only one
of the following functions" (Subclause 10.23.2.4).
Thanks,
Mark
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1