Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <0882eff5-e1c3-8478-a7a8-8344ccd87c22@quicinc.com>
Date:   Fri, 12 Aug 2022 02:53:24 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH v2 2/4] cfg80211: validate RU puncturing bitmap
Content-Language: en-US
To:     Johannes Berg <johannes@sipsolutions.net>,
        <linux-wireless@vger.kernel.org>,
        Aloka Dixit <quic_alokad@quicinc.com>
References: <224a3fb3-df3f-7da3-8130-416a80f116f3@quicinc.com>
 <c1484632-bd03-9992-741f-05b389cd1907@quicinc.com>
From:   Balamurugan Mahalingam <quic_bmahalin@quicinc.com>
In-Reply-To: <c1484632-bd03-9992-741f-05b389cd1907@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


>
>
>
> -------- Forwarded Message --------
> Subject: Re: [PATCH v2 2/4] cfg80211: validate RU puncturing bitmap
> Date: Thu, 24 Mar 2022 09:35:27 -0700
> From: Aloka Dixit <quic_alokad@quicinc.com>
> To: Johannes Berg <johannes@sipsolutions.net>, 
> linux-wireless@vger.kernel.org
>
> On 3/24/2022 3:37 AM, Johannes Berg wrote:
>>
>> (and also, you included all kinds of random other things in these
>> patches, specifically in nl80211.h, so there's no way I can apply them
>> as is anyway)
>>
>
> I had added the other nl80211 parts to match local user-space
> nl80211 order during testing, forgot to take it out.
>
> Let's discuss once your client side version is sent out.
>
> Thanks.


9.4.2.45 Multiple BSSID element (excerpts from Draft 2.0 version)
The Timestamp and Beacon Interval fields, TIM, DSSS Parameter Set, IBSS 
Parameter Set, Coun
try, Channel Switch Announcement, Extended Channel Switch Announcement, 
Wide Bandwidth Channel Switch, Transmit Power Envelope, Supported 
Operating Classes, IBSS DFS, ERP Informa
tion, HT Capabilities, HT Operation, VHT Capabilities, and VHT 
Operation, S1G Beacon Compati
bility, Short Beacon Interval, S1G Capabilities, and S1G Operation, HE 
Capabilities, HE 6 GHz Band Capabilities, HE Operation, BSS Color Change 
Announcement,
and Spatial Reuse Parameter Set , EHT Capabilities, and EHT Operation
elements are not included in the Nontransmitted BSSID Profile 
subelement; the values of these elements for each nontransmitted BSSID 
are always the same as the corresponding transmitted BSSID element values.


Hi Johannes,


I am looking at the change in design and i see the below concerns.

While a BSS level RU puncturing gives the flexibility of configuring 
different puncturing bitmaps in MBSSID scenario, the same cannot be 
advertised on a per BSS basis over the beacon to the stations trying to 
associate with the AP. (with reference to text above from Spec)

1. There is a only one EHT operation element (which holds the disabled 
subchannel bitmap) that can be announced in a MBSSID beacon.
     The spec doesn't allow to announce EHT operation on a per BSS basis.
2. Having a ru_puncturing_bitmap at the chandef level for the AP mode 
could also help us decide easily whether DFS is needed or not (Skip DFS 
if the dfs channels are punctured) .  Having RU puncturing at BSS level 
could again lead to confusion if certain BSSes of a single phy are 
configured with different RU puncturing bitmaps some including the DFS 
channel and some puncturing out all the  DFS channels.

Shall we retain the RU puncturing bitmap at chandef level for the AP 
mode and keep the RU puncturing bitmap at BSS level for the STA scenarios?


From: Johannes

that's probably a discussion better had on the mailing list, rather than 
long-form chat here? :)

not sure it's easy to do with AP/client modes different since we also 
have AP + client concurrency scenarios


Hi Johannes,

I have captured the offline discussions above to set the context for others.

Even in the AP & STA concurrent scenario, i believe this approach should 
work.
     1. In the STA case, The STA shall use the puncture pattern from its 
BSS conf for all transmission to its connected AP.
     2. In the AP case ( MBSSID case as well), the AP  shall use the 
puncture pattern from the chandef while it transmits frame to its 
connected stations.
         The chandef ru_punct_bitmap ultimately gets assigned to the 
virtual interfaces at the driver when virtual interfaces are created.
         The AP vif shall use the value to control the transmissions to 
all its connected stations.
         Since the ru_punct_bitmap is announced over EHT Operation IE, 
the connected stations would limit its transmission only to the 
non-punctured channels.


Could you please share your comments on the above approach?


Thanks

Maha