Atheros Fast-Frames Support
Atheros Fast-Frames support is a Vendor specific extension which concatenates two frames into a single 802.11 MPDU.
It's negotiated as part of the beacon IE and station probe request (TODO: add exactly what).
This was done to mitigate the interframe spacing issue and squeeze some further performance out of the link. Instead of having to do DIFS and exponential backoff on every frame, the fast-frames method would only do it for every other frame. Ie, it would attempt to form an aggregate and then burst that out as one frame, with only one DIFS and back-off period.
For a good set of example timing diagrams, take a look at this:
Since it's transmitted as a single large frame, there's also only a single ACK. So either both frames are transmitted successfully or both are considered as failed.
The net80211 layer intercepts frames destined for a fast-frame capable node and throws them on a per-node, per-AC staging queue.
If a second frame comes in soon enough, it's concatenated with the first frame and has some fast-frames header glue added before it's pushed up to the driver to encapsulate.
Since it's just concatenating two frames together, they must be to the same destination station. Fast-frame aggregation doesn't occur to two different stations in a single aggregate frame.
The fast-frame format is just an 802.3 frame with some specific Atheros-isms:
- Ethertype: 0x88bd
- SNAP header code: 00:03:7f
There's also some rounding/alignment padding going on.
Please see ieee80211_ff_encap() for more details.
The fast frames implementation is in sys/net80211/ieee80211_superg.[ch].
Any driver which supports transmitting and receiving frames up to 3066 bytes (and I'd say a bit more for things like 4-address format support.) Currently this is just ath(4), but I'm sure other drivers support it.
Frame decapsulation is done via ieee80211_ff_decap().
Frame encapsulation is done via ieee80211_ff_encap().
The driver is responsible for calling ieee80211_ff_age() and ieee80211_ff_flush() periodically to ensure that frames on the staging queue do get purged.
Since the aggregation is done in net80211, you can use wlanstats to see if this is occuring:
$ wlanstats -i wlan0 | grep fast 1404337 fast frames decap'd 854866 fast frames encap'd for tx
- It would be nice to implement this for some other drivers as a proof of concept.
- It doesn't currently work for WDS (and unless someone has a need for the kind of improvement it adds for non-802.11n networks, it likely won't grow this).