[[Include(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/TOC)]]

[[TracNav(802.11/TOC)]]

= Characterizing TokenMAC =

Now that we have built TokenMAC, we should characterize the design and identify strengths and weaknesses. There are many ways to do this. Our modifications were minimal in CPU_HIGH. All of the existing structure high-level frameworks will "just work" with our new TokenMAC. So, for example,

* We could simply connect our AP to the Internet via Ethernet and connect our STA to a computer via Ethernet. We will then be able to access the Internet from our computer through TokenMAC. While this would work, it would not provide any visibility into the operation of TokenMAC, so it would be difficult to conclude anything on the merits or demerits of the design.
* Better yet, we can use the existing [wiki:802.11/wlan_exp WLAN Experiments Framework] to construct an experiment and analyzer detailed logs of all transmission and receptions. This will provide deep visibility into the per-packet behavior of the design.

== Two Node, Two Flow Characterization ==

In this section, we will use two existing wlan_exp examples: [wiki:802.11/wlan_exp/examples/txrx_log_capture txrx_log_capture] and [wiki:802.11/wlan_exp/examples/txrx_log_analysis txrx_log_analysis]. Together, these examples set up and analyze a two node, two flow traffic pattern that is broken up into three 20-second phases:

1. In the first 20 seconds, the AP node starts a backlogged traffic source directed to the STA node.
1. In the second 20 seconds, the STA node starts a backlogged traffic source directed at the AP. During this time, the AP's existing traffic flow is left on, so both the AP and the STA are contending for the medium.
1. In the final 20 seconds, the STA node disables its traffic source and only the AP continues to contend for the medium.

For comparison sake, we will run this experiment for both the standard 802.11 unmodified design as well as our custom TokenMAC design. Both experiments use the 18 Mbps PHY rate.

||  [[Image(wiki:802.11/wlan_exp/examples/txrx_log_analysis:log_process_throughput_vs_time_example.png, width=600)]]  ||  [[Image(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/figs:token_xput_annotated.png, width=600)]]  ||
||  ''Standard 802.11'''  ||  ''TokenMAC'''  ||

Clearly, there are some striking differences between the operation of the standard 802.11 MAC and our TokenMAC extension. Two differences are:

1. In the first 20 second period (annotated as "A" in the TokenMAC figure), a standard 802.11 MAC implementation is able to achieve slightly more than 14 Mbps while our TokenMAC implementation could only achieve about 8 Mbps.
1. In the second 20 second period (annotated as "B" in the TokenMAC figure), a standard 802.11 MAC implementation achieves a sum throughput of slightly less than 14 Mbps while our TokenMAC implementation can achieve nearly 16 Mbps.

In the following sections, we will dig deeper into both of these observations and explain them within the context of the TokenMAC protocol.

===  1. Section A: The Zero-Contention Case  ===

In the above figures, we can see that TokenMAC suffers a fairly severe throughput penalty as compared to standard 802.11 in the case that only one flow is using the medium. Using the standard Tx and Rx log files from each node, we have generated a new visualization to show a timeline of events within a short 500 ms window in this regime.

||  [[Image(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/figs:token_A.png, width=1200)]]  ||
||  ''TokenMAC: Section A Timeline'''  ||

The above visualization shows transmissions as vertical bars that extend above the horizontal black line. It shows receptions as vertical bars the extend below the horizontal black line. It is immediately clear why TokenMAC's performance is so poor -- roughly half of the 500 ms period is idle. This is because our TokenMAC implementation still gives the STA a dedicated token reservation period even though it is not using it. In [wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/extensions the extension] section of this tutorial, we will explore a modification to TokenMAC that addresses this weakness.

===  2. Section B: The Heavy-Contention Case  ===

When both flows are active, the above throughput results indicate the TokenMAC exceeds the sum network throughput of standard 802.11. We now use the same log visualization we used in the previous section to see why this is the case:

||  [[Image(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/figs:token_B.png, width=1200)]]  ||
||  ''TokenMAC: Section B Timeline'''  ||

Now that both flows are active, we can see that TokenMAC is no longer "wasting" the medium like it was in the previous zero-contention case. Instead, TokenMAC alternates between the AP and the STA and allows them to send as many packets as they can during that time. Furthermore, because we lack the backoff and ACK overhead of standard 802.11, we are actually able to exceed the standard's sum throughput by a fairly wide margin (16 Mbps vs. 14 Mbps).


=== Analyzing the traffic using Wireshark ===

TokenMAC is, by design, not compliant with the 802.11 Standard. That said, TokenMAC does use the Mango 802.11 Reference Design's PHY to generate 802.11g-compliant OFDM waveforms. As such, standard commercial Wi-Fi devices are capable of decoding every transmission from our TokenMAC implementation (including the custom token offer and token response frames). Using [https://www.wireshark.org Wireshark] on a laptop capable of [https://en.wikipedia.org/wiki/Monitor_mode monitor mode], we have captured the traffic from the above experiment.

||  [[Image(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/figs:wireshark.png, width=1200)]]  ||
||  '''Wireshark Capture'''  ||

The above figure shows a small slice of the capture from Wireshark. It shows the end of a reservation period of the AP followed by the token offer and token response handshake that lead into the STA's reservation period. Because these handshake frames are not standard, Wireshark does not natively know how to extract any information from these frames. Instead, it displays the subtype of "17" for the token offer and "18" for the token response. Recall from [wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/CPU_LOW#NoMAC the CPU_LOW alteration] section the following definitions:

{{{
#!c

#define MAC_FRAME_CTRL1_SUBTYPE_TOKEN_OFFER     (MAC_FRAME_CTRL1_TYPE_CTRL | 0x10)
#define MAC_FRAME_CTRL1_SUBTYPE_TOKEN_RESPONSE  (MAC_FRAME_CTRL1_TYPE_CTRL | 0x20)
}}}

Wireshark computes the "Type/Subtype" value as an 8 bit value, where the 4 LSB is the Type (Control = 0x1) and the 4 MSB is the Subtype (Token Offer = 0x10). This is why these types show up as "17" and "18" in Wireshark.

You can download the Wireshark PCAP file from this experiment here: [http://warpproject.org/dl/app-notes/tokenmac_capture.zip tokenmac_capture.zip (1.7 MB)]