Hi Sanket ,
Thanks for your efforts.
Regarding the following figure, I'm not sure what's the meaning of each phase duration, do you mean it's equal to value in the duration field of the MAC frame? If so, i'm afraid there will be some technical issues, if not, it's better to clarify the new term first.
Thanks
Best Regards
Jay Yang (杨志杰)
Hi Sean/Sanket ,
I am following this interesting discussion, and I would like to offer my view on this topic for your consideration.
The Sharing AP has to be able to cope, i.e. manage in the most graceful manner, with not receiving the ICR from the polled AP. So, we’d better define an efficient method of recovering from that (and returning/freeing the allocated NAV if possible).
I can see the positive argument made about transmitting a response frame in the case of a negative response, for 2 reasons:
The Sharing AP can nicely achieve a sequence of ICF +SIFS +ICR +SIFS +CF-End, without anyone having any doubts or legacy STAs getting confused.
If we use something discussed for In-Device Coexistence in TGbn , i.e. allow the ICR to reduce the TXOP if the Polled AP does not need or plan to use all allocation offered by the Sharing AP, then the ICR is going to be even more useful than providing only a “accept”/”do not accept” response.
For these reasons, I would suggest that transmitting the response frame by the Polled AP is optional (based on first bullet point – the response frame can be lost), but explain the benefits of using the response frame and encourage as such the implementations to use it (even for negative answers; those can reserve the NAV for the CF-End).
I hope this helps.
Best regards,
Michail
From: Sean Coffey <coffey@xxxxxxxxxxx>
Sent: 13 December 2024 18:48
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-C-TDMA
Importance: High
Hi Sanket ,
Thank you for this response, and for iterating with me offline. We continue to be very far apart on this issue.
First, I do not follow your argument below that starts with “as per the baseline”. We are defining an amendment, i.e., changing the baseline. We can define new behavior however we want, as long as the new behavior is compatible with legacy devices. Here, the sharing AP wins a TXOP and signals its intended duration; let’s say it signals 5ms. Long experience has demonstrated that legacy devices will respect that duration, as long as there are no extended gaps. So I do not agree that the baseline imposes any restriction.
Second, I also disagree with your statement below (first sub-bullet) that a negative ICR will “only” help improve performance. The most significant impact is that it will occupy airtime, and thus degrade performance. We are discussing negotiations that will happen entirely within a single TXOP , and that will happen within every TXOP that uses Co-TDMA, so there is no amortization. One of the claimed advantages of Co-TDMA is that there is an overall reduction in time to access the channel; we could easily waste the entire gain with unnecessary PPDUs within the TXOP . In addition, the “performance” you refer to is limited to protection from hypothetical interference from STAs around the polled AP to the intended receivers of any future transmissions by the shared AP in the remainder of the TXOP . To be frank, this seems to be a rather speculative and marginal benefit.
As you state in your first paragraph below, the polled AP may be restricted from responding, for example due to CCA . There might be other reasons, for example in-device coexistence in the polled AP, as I noted when I submitted comments on your PDT draft. Have you considered how a requirement to transmit a negative ICR would be tested in compliance testing, given these multiple exceptions? How could compliant behavior be verified for a device deployed in the field? It seems to me that it would be awkward to test in compliance testing, and impossible to test in the field. I suggest that the IEEE spec will be better if it does not contain requirements of this sort.
Finally, your example involving TID-To-Link Mapping Request and Response doesn’t seem to fit this context. That is a quasi-one-off exchange, so any extra overhead from a response is amortized over a large number of PPDUs . Here we are talking about a requirement that applies in each TXOP using this feature.
Regards,
Sean
From: Sanket Kalamkar <sankal@xxxxxxxxxxxxxxxx>
Sent: Thursday, December 12, 2024 4:11 PM
To: Sean Coffey <coffey@xxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: PDT-MAC-C-TDMA
External mail. |
Hi Sean,
Thank you for sharing your perspective. As we discussed offline and I clarified in my previous e-mail, a response from a polled AP is critical, even if it does not wish to receive time allocation from the Co-TDMA sharing AP, provided the polled AP is not restricted from responding (e.g., due to CCA ).
Regarding your comment:
>>The current PDT seems to instead require the polled AP to send an ICR “whether or not” it wishes to participate, and in particular to send an explicit negative ICR if it is not interested. Why? This really seems utterly unnecessary.>>
Allow me to reiterate the reasons (which I had already mentioned on the reflector):
As per the baseline (10.23.2.2 EDCA backoff procedure), the first frame transmitted by the AP must receive a response for the sharing AP to secure the TXOP . Since the ICF is to be sent at the beginning of the TXOP , if there is no response to the ICF , the sharing AP would need to relinquish the TXOP and contend for the channel again. For instance, in your example of RTS /CTS , if the RTS were the first frame of the TXOP , the STA would lose the TXOP if no CTS response is received to the RTS , as per the baseline.
In the Co-TDMA case, a polled AP sending a negative response will only help improve performance. For example, if the sharing AP polls one AP and that polled AP does not intend to receive the time allocation, providing the response (if it could) can help the sharing AP maintain control of the TXOP ; this wouldn’t be possible if the polled AP stayed silent.
If a polled AP responds (even if it does not intend to receive time allocation), it will keep the medium around it busy for a bit longer: Response duration + SIFS , which will help the sharing AP maintain control of the medium.
For example, if the sharing AP polls two APs on opposite sides, hidden from each other, and only Polled AP#1 responds while Polled AP#2 does not (even though it could), because #2 doesn’t want time allocation in that TXOP , the sharing AP hears only Polled AP#1. A device near Polled AP#2 might then take control of the channel, as it does not detect any ongoing transmission for the duration of the polled response plus 2*SIFS . A negative response from Polled AP#2 would help the sharing AP maintain control.
In addition, there are examples where a STA needs to provide a response even if it is a ‘reject’ response. One example is: “The TID-To-Link Mapping Response frame is sent, by a STA affiliated with an MLD in response to a TID-To-Link Mapping Request frame, to accept or reject a proposed TTLM …” in 9.6.38.3 TID-To-Link Mapping Response frame format (Page 324, 11be D7.0).
Best,
Sanket Kalamkar
From: Sean Coffey <coffey@xxxxxxxxxxx>
Sent: Thursday, December 12, 2024 7:52 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-C-TDMA
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Iñaki,
Thank you for this response. I’m not suggesting that we should limit the number of polled APs ; the current text suggests that we cover one or more AP. The case of sharing with exactly one other AP seems to be an important one, though. I would have thought that this is the most likely case to be used in practice, at least initially.
If the sharing AP wishes to share with exactly one other AP, there is no need for the other AP to provide an explicit negative ICR , since there is no ambiguity about which polled AP is not responding if no response of any sort is received. It is much more efficient for the polled AP to provide a negative response in this way. However, the current PDT seems to require an explicit negative ICR in all cases.
(Even in the case of multiple polled APs , some polled APs may not be able to respond, for various reasons.)
Regards,
Sean
From: Iñaki Val Beitia <0000291ccd900400-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, December 12, 2024 2:08 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-C-TDMA
External mail. |
Hi Sean and Sanket ,
About the ICF /ICR exchange, I remember several things we have to consider. That is, using regular SU RTS /CTS would limit the polling process to only one shared AP, as the CTS response is the same frame for everyone who responds to RTS (having ambiguity). So the question is, are you referring to MU-RTS as ICF , or are you proposing to limit the polling process to one shared AP?
On the other hand, and maybe this is not the right moment to discuss the following topic, but if we consider legacy RTS /CTS frames for the polling process, we are limiting the information exchanged between the sharing and shared APs , which can be very relevant to negotiate an efficient coordination.
Thanks
Iñaki
From: Sean Coffey <coffey@xxxxxxxxxxx>
Sent: Wednesday, December 11, 2024 11:42 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-C-TDMA
Importance: High
This email was sent from outside of MaxLinear .
All,
The issue I raised below (whether a polled AP is required to respond with a negative ICR , if it is not interested in Co-TDMA in this TXOP ) is still unresolved, and it seems as though we may have a lack of consensus on it. If a motion to adopt the current PDT comes up, I plan to make a motion to Amend, implementing the change I proposed below. (This might mean that this has to be dealt with at the January meeting.)
I have iterated with Sanket on this, and will continue to do so, but at this point I think it’s worth throwing it open for broader discussion.
To add slightly to the message below, a polled AP might not respond to a sharing AP’s ICF (for example, due to CCA or in-device coexistence reasons). A sharing AP will treat a lack of a response as a negative response. We seem to have consensus on that, and this is already reflected in the current PDT. The simplest way for the protocol to work then, I suggest, is for the sharing AP to do as it would if it sends an RTS and receives no CTS , i.e., wait a CTSTimeout duration (basically SIFS + 1 slot time after end of its own transmission) and then resume operation, with either trying to share with some other AP or sending in-BSS traffic. This seems to be the natural approach, and it has the benefit of being the most efficient use of airtime.
The current PDT seems to instead require the polled AP to send an ICR “whether or not” it wishes to participate, and in particular to send an explicit negative ICR if it is not interested. Why? This really seems utterly unnecessary.
Regards,
Sean
From: Sean Coffey
Sent: Thursday, December 5, 2024 10:53 AM
To: 'Sanket Kalamkar ' <sankal@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: PDT-MAC-C-TDMA
Sanket ,
Thank you for compiling this r1.
I have one comment. In 37.10.2 (Polling phase), I previously suggested revised wording on the required response to an ICF , but the relevant text does not appear in your r1.
The relevant part of my proposed wording, compared to r1, was:
“A polled AP shall indicate [whether or not] that it intends to participate in the Co-TDMA procedure …”
The following paragraph specifies that if a sharing AP does not receive a response from a polled AP, it shall consider that the polled AP does not intend to participate in Co-TDMA in this TXOP . So there is a fully specified (and presumably satisfactory) way for polled APs to indicate its intention not to participate, and no need for a separate, explicit, negative ICR . Also (as also pointed out by Jay Yang), it might not be possible for a polled AP to respond (since, for example, it may see interference that the sharing AP does not).
The proposed wording above would specify that the requirement is that the polled AP sends a response to indicate that it intends to participate. Under this wording, there would be no requirement to send a response to indicate that it does not intend to participate.
I request that the revised wording above should be included in r2.
Thanks,
Sean
From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, December 4, 2024 12:46 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-C-TDMA
External mail. |
Dear Co-TDMA TTT members,
I received some incredibly constructive feedback from the TTT members on Version 0 of r1 of the IEEE PDT on Co-TDMA. Your active involvement is much appreciated!
After returning from the Thanksgiving break, I’ve put together Version 1 of r1 of the PDT, considering all the comments received on Version 0 of r1 up until November 29th. Attached to this e-mail, you’ll find both the redline and clean versions. Version 1 will be the final version of r1, and I’ve already posted the clean version on the mentor (11-24/1961r1).
The redline version is packed with annotations highlighting the changes and pointing to the comments (and respective commenters ) that inspired them. You can also find comments from all commenters in the multiple attached Word documents. I’ve provided point-by-point responses to each comment in the respective documents. If I’ve accidentally overlooked any of your comments, please let me know!
I kindly ask you to review r1 of the PDT and share any further comments by the end of Friday (December 6th, 11:59 PM Pacific Time). My plan is to prepare r2 of the PDT and post it on the mentor by next Tuesday, December 10th. The goal is to make r2 stable enough so that we can discuss it during one of the IEEE teleconference calls and move forward with the SP/motion.
Thanks again for your invaluable input and cooperation!
Best,
Sanket Kalamkar
From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, November 20, 2024 2:01 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-C-TDMA
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Dear Co-TDMA TTT members,
We made significant progress on Co-TDMA during the November IEEE meeting, with six motions being passed. Based on these motions and the feedback received on r0 (many thanks to Brian Hart!), I have prepared an initial draft of r1 of the PDT.
Attached to this email, you will find both the redline and clean versions of the initial draft of r1 of the PDT. This draft also includes some additional text that I believe is a straightforward extension of the passed motions.
I kindly request your comments and suggestions within the next 24 hours, by 2pm Thursday (Pacific Time).
Additionally, I have attached my point-by-point responses to Brian’s comments on r0.
Best,
Sanket Kalamkar
From: Brian Hart (brianh ) <00000c7561051aea-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, November 19, 2024 10:02 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-C-TDMA
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Sanket
Many thanks for kicking this effort off! My comments attached.
Best wishes
Brian
Cisco Confidential
From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, November 14, 2024 5:19 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] PDT-MAC-C-TDMA
This is the initial email for:
Proposed Draft Text for C-TDMA
As the PoC for C-TDMA, I have created the initial PDT document 11-24-1961r0 for C-TDMA. This document includes proposed text based on the motion passed until September 2024. We will update the PDT as additional motions are passed. The current version r0 is at a very high level, based on just one motion.
The author list in r0 is based on the 1:1 TTT requests received to me after the TGbn Chair’s guideline to send TTT request to PoCs . The author list will be updated based on the list of members in the TTT for C-TDMA (about 80 members) mentioned in the document by Ross 11-24/1698r12. If you wish to be removed from the TTT or the current (and future) author list, please e-mail me at sankal@xxxxxxxxxxxxxxxx. I will update the author list accordingly in the next revised version (r1).
Please send any comments on the draft text (excluding the author list) in 11-24-1961r0 to this e-mail thread. This allows all TTT members to see and discuss your comments, facilitating debate on any changes to the document. This will be our general process for including text in the document.
At some point, as the group passes more motions to C-TDMA, we will try to find volunteers to create draft text sections corresponding to those motions. Depending on the size/complexity of that text, it should appear for discussion within this e-mail thread either as:
Text included directly in an email (for small additions/changes)
Text in a new WORD document sent as an attachment (not an official 802.11 submission)
Text in a copy of the 11-24/1961rx WORD document showing additions and changes, attached to the email thread.
We will aim to discuss any new proposed draft text within this thread and reach a super-majority agreement (e.g., 75% of the TTT membership). However, even 75% is challenging due to the fluid nature of TTT membership. Deciding when to close the debate on new text will be a judgment call, typically when objections reduce to a small number (e.g., less than 25%, or about 15-20 people). If objections persist, we may need to conduct a straw poll in TGbn and update our document 11-24-1961rx based on the outcome. Future text additions will follow a similar process, aiming for super-majority agreement.
Thank you for your cooperation.
P.S. You might have noticed that the guidelines in this e-mail are straight from Matthew Fischer's playbook. Thanks, Matt—it saved me a ton of time and probably a few gray hairs!
Best,
Sanket Kalamkar
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
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