How to disable ACK for wifi mac

[Gary Pei]

Hi,
I need to run experiments with WiFi MAC ACK disabled. What is the
easiest way to do this?
Thanks,
Gary

[Mathieu Lacage]

In DcaTxop::NotifyAccessGranted, change all calls to EnableAck to
DisableAck

Mathieu

[Timo Bingmann]

Use broadcasts.
Greetings
Timo

[Gary Pei]

Timo,
Using broadcast will cause GetStation to return non-unicast basic tx
mode only, higher data rate tx modes can not be used (which is not
what I want).
Gary

On Mar 22, 3:23 am, Timo Bingmann <timo.bingm...@student.kit.edu>
wrote:

[Gary Pei]

Mathieu,

Thanks for the tip.

However, it turned out that it is not that simple.

First, in MacLow::ReceiveOk() line 607, Ack is scheduled without
checking m_txParams.MustWaitAck(). Thus, it will fail assertion at
line 1152 in mac-low.cc.

Second, after changing EnableAck to DiableAck in
DcaTxop::NotifyAccessGranted(), one also has to reset m_currentPacket
to 0. Otherwise, only the first packet can go through.

It will be nice to enable "no ACK" as a generic method that user can
use easily. In real system, this is an option. For example, in Linux,
you can use "iwpriv ath0 noackpolicy" command. This is just a thought.

Thanks,

Gary

On Mar 22, 12:20 am, Mathieu Lacage <mathieu.lac...@sophia.inria.fr>
wrote:

[Timo Bingmann]

On Sunday 22 March 2009 21:27:40 Gary Pei wrote:
> Mathieu,
>
> Thanks for the tip.
>
> However, it turned out that it is not that simple.
>
> First, in MacLow::ReceiveOk() line 607, Ack is scheduled without
> checking m_txParams.MustWaitAck(). Thus, it will fail assertion at
> line 1152 in mac-low.cc.
>
> Second, after changing EnableAck to DiableAck in
> DcaTxop::NotifyAccessGranted(), one also has to reset m_currentPacket
> to 0. Otherwise, only the first packet can go through.
>
> It will be nice to enable "no ACK" as a generic method that user can
> use easily. In real system, this is an option. For example, in Linux,
> you can use "iwpriv ath0 noackpolicy" command. This is just a thought.
>
> Thanks,
>
> Gary

The 802.11(e) standard only allows a NoACK policy on QoS packets. In the base standard only groupcast packets are not acked, unicasts are always acked.

In the attachment a small patch I made to set the wifimode on broadcast/groupcast packet. Only for the ConstantRateManager.

Greetings
Timo

[Gary Pei]

Timo,
Thanks for the patch. This is a good solution.
Best,
Gary

On Mar 22, 2:03 pm, Timo Bingmann <timo.bingm...@student.kit.edu>
wrote:

>  NonUnicastMode.patch
> 2KViewDownload

[Mathieu Lacage]

On Sun, 2009-03-22 at 13:27 -0700, Gary Pei wrote:

> However, it turned out that it is not that simple.

indeed.

>
> First, in MacLow::ReceiveOk() line 607, Ack is scheduled without
> checking m_txParams.MustWaitAck(). Thus, it will fail assertion at
> line 1152 in mac-low.cc.

I don't really understand the above: line 607 is reached through the
following if statement which includes a check for MustWaitAck and is
called on the tx side:

else if (hdr.IsAck () &&
hdr.GetAddr1 () == m_self &&
(m_normalAckTimeoutEvent.IsRunning () ||
m_fastAckTimeoutEvent.IsRunning () ||
m_superFastAckTimeoutEvent.IsRunning ()) &&
m_txParams.MustWaitAck ())

and line 1152 is called on the rx side so, there is no direct immediate
relationship between these two pieces of code: the chain of causal
events leading to the crash must be a bit longer.

> It will be nice to enable "no ACK" as a generic method that user can
> use easily. In real system, this is an option. For example, in Linux,
> you can use "iwpriv ath0 noackpolicy" command. This is just a thought.

Yes, it sounds like a nice feature to have:
1) I am a bit curious what you intend to use this for
2) I am worried that a complete patch would be intrusive: you would need
to make sure that you modify correctly MacLow::CalculateOverallTxTime
and that the DcaTxop class still works correctly after these changes to
MacLow.

i.e., I am trying to evaluate the pros and cons of adding this feature:
if the cost is sufficiently low, we should go for it, but if the cost is
many new if statements in MacLow, and other classes, it is going to be a
tough sell.

Mathieu

[Gary Pei]

>
> > First, in MacLow::ReceiveOk() line 607, Ack is scheduled without
> > checking  m_txParams.MustWaitAck(). Thus, it will fail assertion at
> > line 1152 in mac-low.cc.
>
> I don't really understand the above: line 607 is reached through the
> following if statement which includes a check for MustWaitAck and is
> called on the tx side:
>
>   else if (hdr.IsAck () &&
>            hdr.GetAddr1 () == m_self &&
>            (m_normalAckTimeoutEvent.IsRunning () ||
>             m_fastAckTimeoutEvent.IsRunning () ||
>             m_superFastAckTimeoutEvent.IsRunning ()) &&
>            m_txParams.MustWaitAck ())
>
> and line 1152 is called on the rx side so, there is no direct immediate
> relationship between these two pieces of code: the chain of causal
> events leading to the crash must be a bit longer.
>

Here is what I observed about line 607:

594 else if (hdr.GetAddr1 () == m_self)
595 {
596 WifiRemoteStation *station = GetStation (hdr.GetAddr2 ());
597 station->ReportRxOk (rxSnr, txMode);
598
599 if (hdr.IsQosData () && hdr.IsQosNoAck ())
600 {
601 NS_LOG_DEBUG ("rx unicast/noAck from="<<hdr.GetAddr2
());
602 }
603 else if (hdr.IsData () || hdr.IsMgt ())
604 {
605 NS_LOG_DEBUG ("rx unicast/sendAck from=" <<
hdr.GetAddr2 ());
606 NS_ASSERT (m_sendAckEvent.IsExpired ());
607 m_sendAckEvent = Simulator::Schedule (GetSifs (),
608
&MacLow::SendAckAfterData, this,
609 hdr.GetAddr2 (),
610 hdr.GetDuration
(),
611 txMode,
612 rxSnr);
613 }
614 goto rxPacket;
615 }

So, it only checks the destination address at line 594 before it
reaches line 607. BTW, line 594 "else if" is in parallel with the
following "else if" statement you mentioned, namely, the following:

else if (hdr.IsAck () &&
hdr.GetAddr1 () == m_self &&
(m_normalAckTimeoutEvent.IsRunning () ||
m_fastAckTimeoutEvent.IsRunning () ||
m_superFastAckTimeoutEvent.IsRunning ()) &&
m_txParams.MustWaitAck ())

> > It will be nice to enable "no ACK" as a generic method that user can
> > use easily. In real system, this is an option. For example, in Linux,
> > you can use "iwpriv ath0 noackpolicy" command. This is just a thought.
>
> Yes, it sounds like a nice feature to have:
> 1) I am a bit curious what you intend to use this for

Well, at this moment, I just want to measure raw frame error rate for
single hop under different tx modes. However, I can see many cross-
layer protocol designs may need more flexibility to control MAC
behavior such as ACK. Also, multicast routing protocol may want to set
broadcast rate to higher rate than the basic rate etc.

> 2) I am worried that a complete patch would be intrusive: you would need
> to make sure that you modify correctly MacLow::CalculateOverallTxTime
> and that the DcaTxop class still works correctly after these changes to
> MacLow.
>
> i.e., I am trying to evaluate the pros and cons of adding this feature:
> if the cost is sufficiently low, we should go for it, but if the cost is
> many new if statements in MacLow, and other classes, it is going to be a
> tough sell.
>

Agreed. FYI, I tried both approaches, one is based on your tip with
modifications I described early, the other approach is to use Timo's
patch. Both approaches worked fine for my current purpose. They
produced the same results. It seems to me that Timo's patch can be
viewed as low cost and a generalization of setting broadcast rates. It
may make sense to include that patch.

Best,

Gary

[Mathieu Lacage]

hrm, right: I must have temporarily switched to a parallel dimension:
sorry about this.

Anyway, line 607 as you show it is on the rx side so, it can't check
MustWaitAck which is set on the tx side. Or, maybe you are suggesting
that this code checks WifiMacHeader::IsQosNoAck ? I am afraid that this
would work only for 802.11e-enabled frames.

> Agreed. FYI, I tried both approaches, one is based on your tip with
> modifications I described early, the other approach is to use Timo's
> patch. Both approaches worked fine for my current purpose. They
> produced the same results. It seems to me that Timo's patch can be
> viewed as low cost and a generalization of setting broadcast rates. It
> may make sense to include that patch.

yes, I tried to find a good reason to not take that patch, but it looks
good :)

Mathieu

[Mathieu Lacage]

On Mon, 2009-03-23 at 20:12 +0100, Mathieu Lacage wrote:

> yes, I tried to find a good reason to not take that patch, but it looks
> good :)

timo: you have commit powers so, feel free to push this in ns-3-dev if
it is compatible with raj's release management timeline.

Mathieu

[Mathieu Lacage]

On Mon, 2009-03-23 at 09:44 -0700, Gary Pei wrote:

> > Yes, it sounds like a nice feature to have:
> > 1) I am a bit curious what you intend to use this for
>
> Well, at this moment, I just want to measure raw frame error rate for
> single hop under different tx modes. However, I can see many cross-
> layer protocol designs may need more flexibility to control MAC
> behavior such as ACK. Also, multicast routing protocol may want to set
> broadcast rate to higher rate than the basic rate etc.

I should have pointed this out yesterday but, did you consider
src/devices/wifi/wifi-phy-test.cc ?

i.e.,:
[mlacage@diese ns-3-dev]$ ./build/debug/src/devices/wifi/wifi-phy-test

regards,
Mathieu

[Gary Pei]

>
> I should have pointed this out yesterday but, did you consider
> src/devices/wifi/wifi-phy-test.cc ?
>
> i.e.,:
> [mlacage@diese ns-3-dev]$ ./build/debug/src/devices/wifi/wifi-phy-test

I did not consider this example initially since I needed upper layer
protocols to match a test bed result. Yes, this is a good example for
testing phy only.

Cheers,

Gary

[Michał Woźniak]

We don't want to use the patch provided by Timo. After changing EnableAck to
DisableAck in DcaTxop we encountered the same problem as you did.

Could you tell us how did you solve the first issue? Where should we reset
m_currentPacket?