search

adjacentlink / emane

Distributed wireless network emulation framework
Other
127 stars 37 forks source link

Question on TOS and using IEEE 802.11abg radio model WMM queues #234

Open vivianchiong opened 1 year ago

vivianchiong commented 1 year ago

Hi,

My goal is to simulate sending voice/video traffic using MGEN. My understanding is these are different traffic classes that I want map to different traffic queues using the WMM enabled functionality in the IEEE 802.11abg radio model.

I am using:

My assumption was that if I changed the TOS value in the flow definitions in MGEN scripts, this would change the Class of the flow's traffic (e.g. TOS 96==0x60=>CS3, TOS 64==0x40=>CS2, TOS 32==0x20=>CS1), which should map to all the different queues corresponding to the "four different traffic classes" in the IEEE 802.11abg radio model.

Here is my mgen.script file (node-1):

TTL 64

0.0 LISTEN UDP 5001

0.0 JOIN 225.1.20.1 INTERFACE bmf0

1.0 ON 1 UDP SRC 5001 DST 225.1.20.1/5001 BURST [RANDOM 10.0 PERIODIC [1 1024] EXPONENTIAL 5.0] TOS 0x20 INTERFACE bmf0

20.0 OFF 1

25.0 ON 250 UDP SRC 5002 DST 225.1.20.1/5001 BURST [RANDOM 10.0 PERIODIC [1 1024] EXPONENTIAL 5.0] TOS 0x40 INTERFACE bmf0

40.0 ON 500 UDP SRC 5003 DST 225.1.20.1/5001 BURST [RANDOM 10.0 PERIODIC [1 1024] EXPONENTIAL 5.0] TOS 0x60 INTERFACE bmf0

60.0 OFF 250

900.0 OFF 500

900.0 LEAVE 225.1.20.1 INTERFACE bmf0

900.0 IGNORE UDP 5001

Here is my ieee80211abgmac.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mac SYSTEM "file:///usr/share/emane/dtd/mac.dtd">
<mac name="IEEE 802.11 MAC" library="ieee80211abgmaclayer">
  <param name="mode"                  value="0"/>
  <param name="enablepromiscuousmode" value="off"/>
  <param name="distance"              value="1000"/>
  <param name="unicastrate"           value="4"/>
  <param name="multicastrate"         value="1"/>
  <param name="rtsthreshold"          value="0"/>
  <param name="pcrcurveuri"
         value="file:///usr/share/emane/xml/models/mac/ieee80211abg/ieee80211pcr.xml"/>
  <param name="flowcontrolenable"     value="off"/>
  <param name="flowcontroltokens"     value="10"/>
  <param name="radiometricenable"     value="on"/>
  <param name="retrylimit0"           value="2"/>
  <param name="retrylimit1"           value="2"/>
  <param name="retrylimit2"           value="2"/>
  <param name="retrylimit3"           value="2"/>
  <param name="queuesize0"            value="255"/>
  <param name="queuesize1"            value="255"/>
  <param name="queuesize2"            value="255"/>
  <param name="queuesize3"            value="255"/>
  <param name="wmmenable"             value="yes"/>
</mac>

When I used tcpdump -i bmf0 -nn -v src 10.100.0.1, I saw the TOS values being set (0x20, 0x40, 0x60). However, when I use emanesh to look at the tables and stats, I only see packets accepted/dropped, for example, in queues 0 and 3, and not 1 and 2. 

nem 1   mac BroadcastPacketAcceptTable0
| NEM | Num Pkts Tx | Num Bytes Tx | Num Pkts Rx | Num Bytes Rx |
| 1   | 31          | 24535        | 0           | 0            |
| 2   | 0           | 0            | 77          | 21390        |
| 3   | 0           | 0            | 75          | 20822        |
| 4   | 0           | 0            | 74          | 20720        |
| 5   | 0           | 0            | 75          | 20894        |
| 6   | 0           | 0            | 73          | 20374        |
| 7   | 0           | 0            | 75          | 20902        |
| 8   | 0           | 0            | 76          | 21152        |
| 9   | 0           | 0            | 75          | 20858        |
| 10  | 0           | 0            | 75          | 20962        |
| 11  | 0           | 0            | 74          | 20640        |
| 12  | 0           | 0            | 75          | 20866        |
| 13  | 0           | 0            | 75          | 20902        |
| 14  | 0           | 0            | 1           | 70           |
| 15  | 0           | 0            | 75          | 20866        |
| 16  | 0           | 0            | 75          | 21118        |
| 17  | 0           | 0            | 74          | 20900        |
| 18  | 0           | 0            | 76          | 21068        |
| 19  | 0           | 0            | 75          | 21042        |
| 20  | 0           | 0            | 76          | 21224        |

nem 1   mac BroadcastPacketAcceptTable1
| NEM | Num Pkts Tx | Num Bytes Tx | Num Pkts Rx | Num Bytes Rx |

nem 1   mac BroadcastPacketAcceptTable2
| NEM | Num Pkts Tx | Num Bytes Tx | Num Pkts Rx | Num Bytes Rx |

nem 1   mac BroadcastPacketAcceptTable3
| NEM | Num Pkts Tx | Num Bytes Tx | Num Pkts Rx | Num Bytes Rx |
| 1   | 114         | 16583        | 0           | 0            |

Could there be some system queueing or EMANE/radio model configurations that I'm missing to use all the different queues?

Thank you so much for your help, I truly appreciate it!

vivianchiong commented 1 year ago

I have adjusted my TOS values to match what the corresponding DCSP values would be from here. I suspect that my mgen packets aren't being reached to the other EMANE nodes, because when I inspect the emane.logs, I don't see any packets with packet length 1024 or with my DSCP values.

Is it possible that EMANE nodes are not picking up messages from my multicast interface "bmf0"?

#
# olsr.org OLSR daemon config file
#
# Lines starting with a # are discarded
#
# This file was shipped with olsrd 0.X.X
#
# This file is an example of a typical
# configuration using the LQ extention

# Debug level(0-9)
# If set to 0 the daemon runs in the background

DebugLevel  0

# IP version to use (4 or 6)

IpVersion   4

LockFile "${etce_log_path}/olsrd.lock"

# Clear the screen each time the internal state changes

ClearScreen     yes

LinkQualityAging 0.2

Interface "emane0" "emane1" "eth2"
{
 HelloInterval 1.0
 HelloValidityTime 5.0
}

LoadPlugin "olsrd_txtinfo.so.1.1"
{
PlParam "accept" "0.0.0.0"
}

LoadPlugin "olsrd_bmf.so.1.7.0"
{
PlParam "DoLocalBroadcast" "no" # disable the flooding of local broadcast packets (e.g. packets with IP destination 192.168.1.255)

PlParam "CapturePacketsOnOlsrInterfaces" "yes" # packets sent on the OLSR-enabled network interfaces will be flooded over the OLSR network

PlParam "BmfMechanism" "Broadcast"

#PlParam "NonOlsrIf" "eth2"

PlParam "FanOutLimit" "0" # broadcast is always used, even if there is only 1 neighbor to forward to

PlParam "BroadcastRetransmitCount" "1" # number of times BMF will transmit the same packet whenever it decides to use broadcast to forward a packet
}

The other thing I noticed was that I ONLY see lines like this these using cat emane.log | grep "category 1" and cat emane.log | grep "category 1":

22:48:28.783816 DEBUG MACI 001 WMMManager::getUtilizationRatios: category 2, [total_bw 0.000000, ratio 0.000000], usage [total 0.008576, 8.58%]
22:53:45.283944 DEBUG MACI 001 WMMManager::getUtilizationRatios: category 1, [total_bw 0.000000, ratio 0.000000], usage [total 0.006432, 6.43%]

while Category 0 and 3 have other debug lines from WMMManager for example.

vivianchiong commented 1 year ago

I also have this issue with the TDMA radio model.

After inspecting using tcpdump, I believe the olsr control messages defaulted to a TOS value of 192 (which maps to queue 3) is contributing to BroadcastPacketAcceptTable3. However for the mgen generated traffic, even though tcpdump on the bmf0 interface shows the correctly set TOS values I have in my mgen flows, for some reason when that traffic flows to the emane0 interface and I tcpdump on emane0, the TOS value gets set back to 0, which in turn contributes to the BroadcastPacketAcceptTable0.

Does anyone else have this issue or have any suspicions on why this could be happening? Thanks so much!