Re: Re: adding ba_policy member in drv_ampdu_action op - request information

Re: Re: adding ba_policy member in drv_ampdu_action op - request information

[vivekanandah]

Hi johannes,

kindly find my thoughts below:

if you are referring to the addba-request to transmit a ADDBA with 
delayed block ack, yes, i accept what you have stated. but, then we 
would need to support delayed block ack on the TX.

for my query, i was thinking more with respect to the receive side of 
an AP.

if, let us say a particular station is capable of delayed block ack 
which might not be a linux station(presently it seems, linux box will 
only pursue immediate block ack), then on receive of a block ack 
request, the lower layer can just send an ack if the policy is known to 
be delayed block ack.

It can later decide to send out the actual block ack response in the 
next TXOP. i felt this could be independent of actual support of delayed 
block ack on the TX side. this also provides the entire block ack info 
to the lower layers.

looking forward to your inputs
thanks and regards
Vivek



> -------- Original Message --------
>
> SUBJECT:
> Re: adding ba_policy member in drv_ampdu_action op - request
> information
>
> DATE:
> Wed, 12 Dec 2012 15:17:58 +0100
>
> FROM:
> Johannes Berg  [1]
>
> TO:
> vivekanandah@posedge.com [2]
>
> CC:
> linux-wireless@vger.kernel.org [3]
>
> On Wed, 2012-12-12 at 12:10 +0530, vivekanandah@posedge.com [4]
> wrote:
>> Hi,
>>
>> presently in code, the block ack policy is not sent by mac80211 to
> the
>> lower level driver via the ampdu_action callback.
>>
>> The mac80211 while transmitting a block ack (ADDBA)request,
> hardcodes
>> the block ack methodology to immediate block ack.
>>
>> on the receive side, the delayed block ack bit is checked
> along-with
>> the capability of the receiver station to support delayed block
> ack.
>> even if the station supports delayed block ack, mac80211 does not
> send
>> the ba_policy down to the driver.
>>
>> should ba_policy be sent to the driver so that lower level drivers
> can
>> take a call as to send block ack response in a delayed manner at
> its
>> convenience?
>
> Well, if you wanted to support it, you'd first have to change the
> negotiation to actually ask for it, no?
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org [5]
> More majordomo info at http://vger.kernel.org/majordomo-info.html [6]
>
>
>
> Links:
> ------
> [1] mailto:johannes@sipsolutions.net
> [2] mailto:vivekanandah@posedge.com
> [3] mailto:linux-wireless@vger.kernel.org
> [4] mailto:vivekanandah@posedge.com
> [5] mailto:majordomo@vger.kernel.org
> [6] http://vger.kernel.org/majordomo-info.html

Re: Re: adding ba_policy member in drv_ampdu_action op - request information

[Johannes Berg]

Hi Vivek,

> if you are referring to the addba-request to transmit a ADDBA with 
> delayed block ack, yes, i accept what you have stated. but, then we 
> would need to support delayed block ack on the TX.
> 
> for my query, i was thinking more with respect to the receive side of 
> an AP.

Ah, ok.

> if, let us say a particular station is capable of delayed block ack 
> which might not be a linux station(presently it seems, linux box will 
> only pursue immediate block ack), then on receive of a block ack 
> request, the lower layer can just send an ack if the policy is known to 
> be delayed block ack.

Right now, a mac80211-based station should probably never even advertise
that it is delayed-BA capable since it won't correctly be handled.
Therefore, any other station must not ask for a delayed-BA session in
its AddBA request. And in fact, ieee80211_process_addba_request() drops
frames that ask for delayed BA.

So I guess what you're really saying is that you want to implement
delayed BA and address the todo item in
ieee80211_process_addba_request() that says:

        /* XXX: check own ht delayed BA capability?? */

i.e. add a check here for our own capability and add a new parameter to
let the driver know...

Overall that seems reasonable.

johannes

Re: Re: adding ba_policy member in drv_ampdu_action op - request information

[vivekanandah]

hi johannes,

sorry for the delayed response. i was off from work for a few days.

is'nt the station's capability and the AP capability intersected during 
association? i always thought that the comment was mis-represented.

i did a small test and i see that the stations capability is actually 
the subset of AP capabilities that both support.
if that is the case, then we do not have to check for the capability 
independently there! do i miss something in my understanding?

also, if what i have stated above is correct, then yes, i feel delayed 
block ack as a feature might need to be implemented on mac80211 and then 
check for the same.

thanks and regards
Vivek


On Thu, 13 Dec 2012 15:01:59 +0100, Johannes Berg wrote:
> Hi Vivek,
>
>> if you are referring to the addba-request to transmit a ADDBA with
>> delayed block ack, yes, i accept what you have stated. but, then we
>> would need to support delayed block ack on the TX.
>>
>> for my query, i was thinking more with respect to the receive side 
>> of
>> an AP.
>
> Ah, ok.
>
>> if, let us say a particular station is capable of delayed block ack
>> which might not be a linux station(presently it seems, linux box 
>> will
>> only pursue immediate block ack), then on receive of a block ack
>> request, the lower layer can just send an ack if the policy is known 
>> to
>> be delayed block ack.
>
> Right now, a mac80211-based station should probably never even 
> advertise
> that it is delayed-BA capable since it won't correctly be handled.
> Therefore, any other station must not ask for a delayed-BA session in
> its AddBA request. And in fact, ieee80211_process_addba_request() 
> drops
> frames that ask for delayed BA.
>
> So I guess what you're really saying is that you want to implement
> delayed BA and address the todo item in
> ieee80211_process_addba_request() that says:
>
>         /* XXX: check own ht delayed BA capability?? */
>
> i.e. add a check here for our own capability and add a new parameter 
> to
> let the driver know...
>
> Overall that seems reasonable.
>
> johannes

Re: Re: adding ba_policy member in drv_ampdu_action op - request information

[Johannes Berg]

On Thu, 2012-12-20 at 02:39 -0800, vivekanandah@posedge.com wrote:

> is'nt the station's capability and the AP capability intersected during 
> association? i always thought that the comment was mis-represented.
> 
> i did a small test and i see that the stations capability is actually 
> the subset of AP capabilities that both support.
> if that is the case, then we do not have to check for the capability 
> independently there! do i miss something in my understanding?
> 
> also, if what i have stated above is correct, then yes, i feel delayed 
> block ack as a feature might need to be implemented on mac80211 and then 
> check for the same.

I don't see what difference that makes? You still have to implement the
feature fully, we don't have support for it at all.

johannes

Re: Re: adding ba_policy member in drv_ampdu_action op - request information

[vivekanandah]

hi johannes,

i agree on that count :)

thanks and regards
Vivek





On Thu, 20 Dec 2012 12:40:05 +0100, Johannes Berg wrote:
> On Thu, 2012-12-20 at 02:39 -0800, vivekanandah@posedge.com wrote:
>
>> is'nt the station's capability and the AP capability intersected 
>> during
>> association? i always thought that the comment was mis-represented.
>>
>> i did a small test and i see that the stations capability is 
>> actually
>> the subset of AP capabilities that both support.
>> if that is the case, then we do not have to check for the capability
>> independently there! do i miss something in my understanding?
>>
>> also, if what i have stated above is correct, then yes, i feel 
>> delayed
>> block ack as a feature might need to be implemented on mac80211 and 
>> then
>> check for the same.
>
> I don't see what difference that makes? You still have to implement 
> the
> feature fully, we don't have support for it at all.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html