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:
> [email protected] [2]
>
> CC:
> [email protected] [3]
>
> On Wed, 2012-12-12 at 12:10 +0530, [email protected] [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 [email protected] [5]
> More majordomo info at http://vger.kernel.org/majordomo-info.html [6]
>
>
>
> Links:
> ------
> [1] mailto:[email protected]
> [2] mailto:[email protected]
> [3] mailto:[email protected]
> [4] mailto:[email protected]
> [5] mailto:[email protected]
> [6] http://vger.kernel.org/majordomo-info.html
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
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, [email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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
On Thu, 2012-12-20 at 02:39 -0800, [email protected] 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