Understanding WiFi retransmissions

[Sebastian Lindner]

Our application sends small 470B data packets, for which we would like to disable WiFi retransmissions. The right place to consider this seems to be the WifiRemoteStationManager, which has two retransmission counters:

1) MaxSsrc, which is used for all packets whose size is <= RtsCtsTreshold

2) MaxSlrc, which is used for all packets whose size is > RtsCtsTreshold

so we set the RtsCtsThreshold to 469B, which leads to all our packets being >threshold, hence the MaxSlrc value is used, which we set to zero. And RTX are off, nice! However, we don't really wish to enable RTS/CTS for our packets, either.

If we leave the threshold untouched (its default is at 65535), but set the MaxSsrc=0, then all control packets such as association requests are also not retransmitted, which leads to everything breaking. Also, besides our data packets, we have custom control packets as well, which are likewise very small (~100B), and these should also be retransmitted.

We've also tried tinkering with the bool
WifiRemoteStationManager::NeedRetransmission(Ptr<const WifiMpdu> mpdu) function itself. Ideally we want to selectively react to only our data packets and not retransmit those. However, we couldn't find any way to do this, because packets are often aggregated. Therefore we cannot filter by size (as sizes change when data is aggregated). And we cannot filter by header, because if one of our control packets is aggregated into an A-MPDU, then the header is identical to a data packet header (QOS_DATA).

Questions:

How could we selectively retransmit everything but our data packets?

How could we prevent our custom control packets from being aggregated together with data packets?

[Tom Henderson]

Is this a capability defined in the standard, that one should be able to
selectively disable retransmissions for some class of data traffic (such
as for a particular access category)?

If you just need to do this for your own study, and you can detect these
packets (perhaps based on packet size) in the Wi-Fi code, have you
considered to hack in some code that will suppress retransmissions for
these packets?

- Tom

> --
> Posting to this group should follow these guidelines
> https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
> <https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting>
> ---
> You received this message because you are subscribed to the Google
> Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ns-3-users+...@googlegroups.com
> <mailto:ns-3-users+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ns-3-users/ade47c75-36d6-400b-ac2d-0a286480542an%40googlegroups.com <https://groups.google.com/d/msgid/ns-3-users/ade47c75-36d6-400b-ac2d-0a286480542an%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Sebastian Lindner]

No, it's not in the standard. I'd like to do what you're proposing, but due to packet aggregation, I see no way to detect our two different types of packets. Do you know how we could prevent a packet from being aggregated? Then we could differentiate based on the headers - but once packets are aggregated, the A-MPDU always gets the same header, no matter what's inside.

[Tom Henderson]

Couldn't you just implement custom logic within

WifiRemoteStationManager::NeedRetransmission(Ptr<const WifiMpdu> mpdu)

based on the size of the MPDU?

> https://groups.google.com/d/msgid/ns-3-users/ade47c75-36d6-400b-ac2d-0a286480542an%40googlegroups.com <https://groups.google.com/d/msgid/ns-3-users/ade47c75-36d6-400b-ac2d-0a286480542an%40googlegroups.com> <https://groups.google.com/d/msgid/ns-3-users/ade47c75-36d6-400b-ac2d-0a286480542an%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/ns-3-users/ade47c75-36d6-400b-ac2d-0a286480542an%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> Posting to this group should follow these guidelines
> https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
> <https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting>
> ---
> You received this message because you are subscribed to the Google
> Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ns-3-users+...@googlegroups.com
> <mailto:ns-3-users+...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ns-3-users/c43d9c32-bec5-47eb-957e-32bca976fc9en%40googlegroups.com <https://groups.google.com/d/msgid/ns-3-users/c43d9c32-bec5-47eb-957e-32bca976fc9en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Sebastian Lindner]

This also won't work due to the aggregated packets, whose sizes vary depending on what's inside. If we could stop our custom control packets from being aggregated, then it'd be easy, which is why I ask whether that can be achieved.

Other than that we could deconstruct aggregated packets to check each packet inside, but that's very inefficient.