Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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")



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

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

 

--

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

 


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


This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature