Implementing Packet Aggregation in the Linux Kernel1

Implementing Packet Aggregation in the Linux Kernel1,Jonas Brolin,Peter Dely,Mikael Hedegren,Andreas Kassler

Implementing Packet Aggregation in the Linux Kernel1  
BibTex | RIS | RefWorks Download
In multi-hop wireless mesh networks (WMN) Voice over IP (VoIP) suffers from large overhead created by th e IP/UDP/RTP/MAC header and time due to collisions. As a result the VoIP capacity of WMNs is small. As sho wn in (1) a 3 hop WMN at a data rate of 2Mbit/s can only support 3 concurrent VoIP calls. (1), (2) and (3) p ropose the use of packet aggregation in order to reduce th e overhead and thus increase the capacity. The idea b ehind packet aggregation is to combine multiple small pac kets into a single larger one, reducing overhead and col lision probability in multi-hop environment. This paper pr esents insights into an implementation of an aggregation s cheme in the Linux Kernel and its experimental evaluation . Packet aggregation is typically implemented togethe r with packet queuing. When packets are available for MAC layer transmissions, packets for a common next hop or common destination (e.g. the mesh portal or gate way towards the internet) are combined to a larger pack et and afterwards processed further in the network stack. The Linux Kernel provides several facilities suitable f or queuing and manipulating packets. Those are the Netfilter subsystem, the traffic control subsystem and the so ftware MAC/network card driver. The first possible variant is to write a Netfilter Module (4). A Netfilter module is either a kernel module o r a user space application which interacts with the firewall subsystem by retrieving, storing, manipulating and returning packets. A drawback of Netfilter modules for packet aggregation is the possibility of double del ay and missed aggregation opportunities. Packets are delay ed and aggregated in the Netfilter Modules and passed to t he traffic control subsystem (5). If the egress device is busy, packets are also queued there. Thus additional dela y is added and aggregation opportunities are neglected. To avoid this problem the aggregation can be implemented in the network card driver or the softw are MAC. The network card driver contains a very short buffer - usually only one packet - which stores the packet that is sent after the packet which is currently wa iting in the hardware buffer of the network card. Here packe ts can be aggregated right before the next packet is reque sted for transmission. However this approach is not feasible in practice, since the aggregated packet needs to be r eady for sending as soon as the network card is idle and req uests a new packet. (6) shows that using such an approach t he processing speed of a normal CPU is not enough to immediately provide an aggregated packet. The result is unnecessary performance degradation. Thus (6) suggests implementing packet aggregation in hardware. A third approach is to aggregate packets in the tra ffic control subsystem. Here packets are queued if the M AC is busy. Since there is still a small buffer of packet s in the MAC layer, this eases the requirement of having an aggregated packet ready as soon as the medium becomes idle on the cost of missing some aggregation opportunities. The benefits of this approach are th e possibility of creating very flexible queue hierarc hies and the performance of Kernel Code. Therefore our implementation follows this approach.
Cumulative Annual
View Publication
The following links allow you to view full publications. These links are maintained by other sources not affiliated with Microsoft Academic Search.