Jonas Brolin, Peter Dely,

1
Experimental Evaluation of Packet Aggregation
with Linux and ns-2

• Jonas Brolin, Peter Dely,
• Mikael Hedegren, Andreas Kassler
• Karlstad University
• 8th Scandinavian Workshop on Wireless Ad-hoc
  Sensor Networks
• May 7-8th 2008, Stockholm

2
Outline

• Introduction to Packet Aggregation
• Related Work
• Implementation in Linux
• Linux Testbed
• Testbed Setup
• Results
• Ns-2 Simulations
• Simulation Setup
• Results
• Conclusion and Open Questions

3
Introduction to Packet Aggregation

• IEEE 802.11 MAC has large overhead for small
  packets (e.g. VoIP packets)
• Packet Aggregation
• Combine multiple small packets into a larger one
• Reduce overhead
• lower MAC utilization
• less collisions
• Increase capacity
• Packet aggregation can be done on IP or MAC
  level, hop-by-hop or end-to-end (IP only)

Fig. 1 Transmission Times of a G.729 frame over
IEEE 802.11 2mbit/s, Total time 1186µs
Fig. 2 Principle of Packet Aggregation
4
Related Work and Goals

• Implementation of Packet Aggregation - Related
  Work
• Jain A. et al "Benefits of Packet Aggregation in
  Ad-Hoc Wireless Network
• Packet aggregation as module for click router
• Click router itself is an extension to Linux
  kernel
• Programming language for routers
• Jung S. et al "Voice Transmission Enhancing
  Model on Wireless Mesh Networks
• Combined packet aggregation and header
  compression
• Software implementation can be too slow ? packet
  aggregation and header compression should be done
  in hardware
• IEEE 802.11n/Vendor specific extensions
• IEEE 802.11n can aggregate MPDUs to A-MPDUs or
  A-MSDUs
• Similar, but vendor specific concepts for pre
  IEEE 802.11n components
• Our Goals
• Useable on standard Linux
• Hardware independent
• Configurable and extendable
• Suitable for multi-hop networks

5
Extension of the Linux Networking Stack

• Aggregation
• TC queue object
• Details next slide
• Deaggregation
• Kernel module
• Attached to first netfilter hook
• Every incoming packet is sent to module
• Configuration
• /usr/sbin/iptables
• Configure which packets should be aggregated
• Using mangle table to set a mark on those packets
• /usr/sbin/tc extension
• Control parameters of aggregation queue
• Statistics
• Virtual file in /proc
• Statistics about how many packets are aggregated,
  aggregation ratios etc.

Fig. 3 Schematic view of the Linux Networking
Stack
6
Aggregation Queue

• Traffic classification based on mark set by
  iptables
• Queuing structure
• Two levels
• Top level is round robin scheduler
• FIFO queue for normal traffic
• Aggregation queue for VoIP traffic
• Algorithm
• Forced delay
• Hop-by-hop aggregation
• Controlled by SIZEmin, SIZEmax, Tdelay

Fig. 4 Queuing Architecture
7
Aggregation Queue

• Traffic classification based on mark set by
  iptables
• Queuing structure
• Two levels
• Top level is round robin scheduler
• FIFO queue for normal traffic
• Aggregation queue for VoIP traffic
• Algorithm
• Forced delay
• Hop-by-hop aggregation
• Controlled by SIZEmin, SIZEmax, Tdelay

Fig. 5 Aggregation Algorithm
8
Testbed Setup

• Setup
• Ubuntu 7.10 with kernel version 2.6.22
• AODV-UU as routing protocols
• MAC filter to force topology
• IEEE 802.11b with data rate set to 2Mbit/s
• Traffic generation
• Multi Traffic Generator (mgen)
• 50 UDP packets with 60 bytes per second during
  talkspurts
• 1.5 sec talkspurt/1.0 sec silence, exponentially
  distributed
• Simulates ITU G.729a with Voice Activity
  Detection
• Traffic between Nodes A/D, B/D and the reverse
  directions
• Each test runs for 180 seconds
• With each test 4 more flows are generated

Fig. 6 Testbed Topology
9
Test Results 1/2

• Packet loss ratio, end-to-end delay and jitter
  are important for VoIP quality
• Results
• As traffic increases packet loss ratio,
  end-to-end delay and jitter remain low up to a
  certain point
• Afterwards MAC layer cannot serve new requests
• ? packet loss ratio, delay and jitter increase
  sharply

Fig. 7 Packet loss ratio, end-to-end delay and
jitter
10
Test Results 2/2

• A flow is regarded as supported when
• Packet loss ratio lt 5
• End-to-end delay jitter lt 200ms
• Low, but acceptable quality
• Results
• No aggregation 24 flows
• With aggregation 52 flows
• Some flows are not supported before capacity
  threshold

Capacity Increase
Fig. 8 Number of supported flows vs. number of
injected flows
11
Simulation Setup

• Simulation with ns-2 2.26
• Same algorithm as in testbed
• Settings
• IEEE 802.11a (24Mbit/s) DCF node
• RTS/CTS deactivated
• Shadowing model
• AODV-UU
• MAC/PHY Extended channel model (realistic
  consideration of bit errors)
• Traffic generation
• VoIP extension from Bacioccola et. al
• Creates realistic traffic patterns
• Simulates jitter buffer
• Calculates MOS for each flow
• Topology
• Simple topology, minor impact of routing protocol
• CS Range ca. 150 Meter
• Connections between nodes A-C, B-C, C-A und C-B
• Aggregierung on wireless links
• No node mobility

Fig. 9 Simulation Topology
12
Simulation Results

• Perceptual Quality with MOS
• Takes into account jitter buffer
• Supported Flow MOS gt 3.5
• Capacity 95 of flows are supported
• Results
• No Aggregation 80 flows
• Aggregation 354 flows
• Reduction of MAC layer utilization
• MAC busy time time in which a node experiences
  the medium as busy
• Measure of local contention
• But MAC utilization of hidden nodes is not taken
  into account
• Results
• At 80 concurrent flows aggregation reduces MAC
  busy time by 65
• At 350 flows with aggregation the MAC busy time
  is about as high as with 80 flows and no
  aggregation

Fig. 10 Average MOS
Fig. 11 MAC Busy Times
13
Conclusion and Future Work

• Packet aggregation improves capacity
  significantly
• Simulation shows similar trends
• Open Questions/Points
• Adapt to network load and traffic type
• Integration of a module for limiting background
  traffic
• Configuration of delay/size thresholds based on
  traffic and link quality
• Traffic mix
• Round robin is not a good strategy, especially in
  presence of VoIP
• How to mix traffic?
• Test in larger environment
• KAU will install a testbed with gt 20 nodes
• Include end-users into tests
• Comparison of simulation and real tests

14
Thank you!Peter Delypeter.dely_at_kau.se