| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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>
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):
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>
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>
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>
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
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 [ 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>
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>
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>
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>
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:
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 |