BaCon: A User-Friendly Bandwidth Controller System

BaCon: A User-Friendly Bandwidth Controller System Sirikarn Pukkawanna, Tanachai Kongpool, and Panita Pongpaibool National Electronics and Computer Technology Center (NECTEC) 112 Phahol Yothin Rd., Klong Luang, Pathumthani 12120 Thailand {sirikarn.pukkawanna, tanachai.kongpool, panita}@nectec.or.th Abstract This paper describes the concept and implementation of the Bandwidth Controller (BaCon) system which is designed to provide simple control over Internet bandwidth usage for small and medium enterprises. Our system provides a user-friendly web-based user interface, suitable for organizations which may lack skilled network administrators. Key features of the proposed system include long-term archives of bandwidth usage, detailed report, and the ability to periodically schedule the control. Moreover, the system offers convenient provisioning of bandwidth control policies through pre-defined sets of rules as well as flexible provisioning through user-defined rules. BaCon leverages strengths of Linux utilities, namely tc, iptables and l7- filter, to achieve accurate traffic classification for various popular applications. Keywords bandwidth management, traffic control, traffic shaping, traffic classification, iptables I. INTRODUCTION AND MOTIVATION Network Quality of Service (QoS) is especially important for the new generation of Internet applications such as voiceover-ip, video-on-demand and peer-to-peer (P2P) applications. Some core networking technologies like Ethernet were not designed to support prioritized traffic or guaranteed performance levels, making it much more difficult to implement QoS solutions across the Internet. The goal of QoS is to provide guarantee on the ability of a network to deliver predictable performance. Elements of network performance within the scope of QoS often include availability (uptime), bandwidth (throughput), latency, and error rate. Traffic control is used to manage traffic for Quality of Service (QoS). It helps to improve network latency, service availability and bandwidth utilization by attempting to prioritize network resources and guarantee bandwidth levels based on predefined policies. Traffic control requires elements such as admission control (to discard or mark packets), traffic classifier (to sort or separate packets into queues), scheduler (to arrange packets into queues), and shaper (to delay packets to meet a desired rate). Linux offers a very powerful tool for traffic control, namely tc [1]. tc is a useful Linux command line tool for configuring the kernel structures required to support traffic control. The tc command line utility has an arcane and complex syntax, even for a simple operation. This makes it extremely difficult for a novice user to properly operate traffic control on Linux. As a result, there are many open-source software tools for configuring Linux tc such as MasterShaper [2], WonderShaper [3] and IPCop [4]. The limitation of these open-source software tools is that users still need to understand the underlying control mechanism in details to properly configure the tool. In addition, software installation requires kernel patching and kernel compilation, which is a complicated task for inexperienced Linux users. This paper describes the concept and implementation of the Bandwidth Controller (BaCon) system which is designed to control traffic using the Linux tc command. Our system provides an easier way to setup and configure Linux tc than existing software. BaCon is designed for user with little experience of the Linux system and traffic control mechanism. Users can manage and manipulate traffic via BaCon s userfriendly web interface. We offer pre-defined policies for shaping a group of popular applications such as chat, web, and peer-to-peer applications so that users do not need to know technical specifications (e.g., port number or traffic pattern) of such applications. Our system provides long-term statistics of controlled bandwidth usage reported in forms of graphs and spreadsheets. II. RELATED WORK A. Traffic Control with Linux tc tc is the set of tools which allows users to have granular control over the queuing mechanisms of a network device. It interacts with the Linux kernel to direct the creation, deletion and modification of traffic control structures. It can set up various kinds of queues and associate traffic classes with these queues. It can also set up filters by which the packets are classified. tc consists of six main components namely shaping, scheduling, classifying, policing, dropping, and marking. Policing limits traffic at the ingress. If the traffic exceeds its allowed rate, the dropping component may discard it. Once traffic passes the ingress, it is put into output queue whereby the Scheduling and Shaping components at the egress arrange and hold up its departure time. Processing of traffic is controlled by three kinds of object namely class, qdisc, and filter. The class object offers shaping capabilities. The qdisc object is a scheduler, which can be as simple as FIFO or complex containing many classes and other qdiscs. The filter

object performs traffic classification through the agency of a classifier. B. Linux Traffic Classifiers To classify packets for traffic control, one can use built-in classifiers in tc, or use the marking capability of the Linux firewall. Examples of built-in classifiers in tc are u32 and fw [5]. The u32 classifier decides which queue a packet should be placed into based on fields within the packet (e.g., source IP address, destination port, etc.). The shaping command can be done in a single tc command. For example to shape web traffic, the command is #tc filter add dev eth0 protocol ip parent 10: prio 1: u32 match ip dport 80 0xffff flowid: 10:1 With the fw classifier, tc relies on the marking performed by the firewall. One can shape web traffic using these commands. #iptables -A PREROUTING -t mangle -i eth0 --dport 80 -j MARK --set-mark 9 #tc filter add dev eth0 parent 10: protocol ip prio 1 handle 9 fw flowid 10:1 The Linux kernel firewall Netfilter/iptables marks specific packets in the mangle table. Marking values may be used to send different packets through different routes and to tell them to use different queue disciplines (qdisc). iptables allows marking based on transport header matching as well as on packet payload string pattern matching. Examples of string matching modules to be used in conjunction with iptables are l7-filter [6] and ipp2p [7]. The l7-filter identifies packets based on application-layer data pattern. It can effectively identify applications which use dynamic ports, such as P2P, games, and multimedia streaming. On the other hand, ipp2p focuses on identifying P2P applications only. Sample commands for shaping Bittorrent packets using l7-filter are script which implements a set of rules to provide quality of service and manage the bandwidth between LAN and WAN interfaces. It was designed to minimize ping latency, ensure that interactive traffic like SSH is responsive while downloading or uploading bulk traffic. One disadvantage of IPCop is that when you install IPCop, it will format and copy itself to your hard drive. Moreover, IPCop consists of several components, modules and add-ons. It is sometimes hard to configure. III. CONCEPT AND IMPLEMENTATION OF THE BACON This section describes system architecture of BaCon, our proposed bandwidth controller. This section aims to give insights into overall system design and implementation, and to provide comparison of BaCon against existing bandwidth management tools. A. BaCon System Architecture BaCon system architecture consists of a Linux-based server which serves as an Internet gateway, as well as a web server and a database server. The server must have at least two network interfaces; one connected to the Local Area Network (LAN) and the other to the Internet (WAN). To control all network traffic, BaCon should be placed such that it sees all communications to and from the local network. Inbound traffic is data that comes into a local network from an external host while outbound traffic is generated by a local host going to the Internet. According to the scenario shown in Figure 1, to shape inbound and outbound traffic, tc commands must be activated at interface eth0 (WAN interface) and eth1 (LAN interface) respectively. #iptables -t mangle -A PREROUTING -m layer7 --l7proto bittorrent -j MARK --set-mark 9 #tc filter add dev eth0 parent 10: protocol ip prio 1 handle 9 fw flowid 10:1 C. Existing Open-Source Traffic Shapers MasterShaper is a network traffic shaper which provides a web interface which lets user defines bandwidth pipes and filters based on IP addresses, MAC addresses, ports, protocols, and applications, for example. It also draws some graphs about the current bandwidth usage and distribution. MasterShaper works with iptables and tc to manage traffic. The limitations of MasterShaper are that it is designed for experienced users, hard to setup, configure, and use. Moreover, It does not support long-term statistics of past bandwidth usage. IPCop is a firewall which does proxy/cache, intrusion detection and bandwidth management. IPCop uses WonderShaper for traffic shaping. WonderShaper is a Bash Figure 1. BaCon system architecture BaCon utilizes Linux firewall iptables and tc for traffic marking, scheduling, and shaping. It uses tc_collector.pl which is a perl script modified from that of MasterShaper to collect traffic statistics from the tc utility. tc_collector.pl runs as runs as a background process on the system and collects throughput of each tc class. The difference between our tc_collector.pl and that of MasterShaper is that ours collects tc data into a Round Robin Database (RRD) [8] every 60 seconds (default value, can be adjusted) while MasterShaper collects data into MySQL database every second. The RRD archives are more lightweight and suitable for time-series data than MySQL. By using RRD archives, users can control archive size (i.e., disk space) instead

of letting the database grows indefinitely like in the case of MasterShaper. BaCon s default RRD archives size is six months. This means old data will be replaced with new data after six months. This time period can be configured by users. BaCon interacts with users via a web interface. The GUI is implemented using PHP, Javascript, and AJAX. Network administrators can easily allocate bandwidth for each or a group of applications or IP addresses depending on traffic direction (inbound or outbound). In addition to fine-grained bandwidth allocation, BaCon allows users to drop traffic based on applications or IP addresses as well (i.e., performing a firewall function). Netfilter/iptables is used for firewall function. In addition, iptables marks target packets that matches the allocation policies before passing them into queues in tc. BaCon uses two scheduling algorithms; HTB (Hierarchical Token Bucket) [9] and SFQ (Stochastic Fairness Queuing) [10]. HTB is a classful scheduling algorithm that lets user define minimum and maximum bandwidth bounds for each class, and can give priority to latency-sensitive traffic. Unlike HTB, SFQ tracks TCP and UDP connections and balances traffic between classes. tc controls traffic that are both marked by iptables filter and by u32 filter. Network administrators can carry out both shaping and dropping controls without having to know the syntax of tc and iptables commands. BaCon will automatically convert users input to a set of tc and iptables commands to execute. This adds convenience, and at the same time, greatly reduces configuration errors. B. Managing BaCon Rules and Policies In BaCon, we propose a concept of bandwidth control rules and policies. A BaCon rule is a single action performed by users. For example, a user may want to drop everything except web and FTP traffic. This action is considered a single rule although it may translate to multiple iptables commands: 1) deny all, 2) allow port 80, 3) allow port 443, and 4) allow port 21. With this, user can manipulate the set of commands in one click. Users can specify following attributes for each BaCon rule: rule name*, rule description, traffic direction* (incoming, outgoing, or both), source/destination IP address (all or a set of IP), ports or application, action* (drop or shape), rate limit (in case of shape), scheduled date and time, and status* (active/inactive). The attributes with * are required. The rest is optional. A BaCon policy is a collection of one or more BaCon rules. Policies help network administrators to manage a group of related rules. For instance, users may group rules associated with specific users into one policy, or rules associated with the same network interface into another policy. BaCon allows users to manage create reports on a selected policy in forms of graphs and spreadsheet files. Each BaCon policy has following attributes: policy name*, policy description, and one or more BaCon rules*. For example, a user may create a student policy to encompass a rule for shaping FTP, a rule for blocking a virus-infected PC, and a rule for shaping all outgoing traffic. Figure 2. BaCon process Figure 2 shows the internal process of BaCon for controlling the three rules under the student policy. Dropping outgoing packets of from the virus-infected PC, e.g., Toggle status edit delete show history show graphs Figure 3. Sample of BaCon screenshot

192.168.1.2, involves only one iptables drop command. To shape incoming/outgoing FTP traffic from student IPs at 20 Mbps, on the other hand, requires two steps. First, iptables classifies and marks FTP packets that belong to student IPs. Then, the marked packets are shaped by tc. Lastly, to limit all outgoing traffic at 30 Mbps, except that of 192.168.1.2 which has already been dropped, we can specify the whole subnet, e.g., 192.168.1.0/24 and shape using the u32 classifier under tc. Possible actions for each rule includes create, edit, delete, activate, and deactivate. We offer two ways to create a new BaCon rule. The easiest way is to select from a list of predefined rules. For example, we provide pre-defined rules for controlling instant messaging traffic, bittorrent traffic, and web traffic. This feature helps inexperienced users add a rule for popular applications without paying attention to complex settings. For instant messaging applications, we shape port 1863, 6667, and 6891 to 6900 [11], as well as packets marked by netfilter-l7 as msnmessenger, aim, and irc. For web applications, we shape port 80, 443, 8000, and 8080, and packets marked as http by netfilter-l7. For bittorrent, shaped ports are 6881 to 6889 [12], and l7 marker is bittorrent. A more flexible way to create a new BaCon rule is for users to define their own rules by specifying all attributes mentioned previously. Users may add a new rule without activating it. Inactive rules remain in the BaCon system database but are not executed in iptables and tc. The capability to deactivate rules without deleting them allows users to schedule an active period for each rule. BaCon s user-friendly GUI currently lets users set hour-of-day and day-of-week for a rule to become active, such as every Monday, or every work hour on every weekday. Users can edit both active and inactive rules. Rules will be executed immediately when the new configuration is saved. All actions and modifications to the rule and policy attributes are recorded and stamped with time and username of the one that makes modification. The rules can be exported to file in formats of Excel or CSV (comma separated values). Users can monitor long-term bandwidth usage for each shaped rules. Figure 3 shows some sample BaCon rules and policies. C. Security Considerations This section describes two security issues in BaCon and how we handle them. The first issue concerns network security policy conflicts. For BaCon to work effectively, rule and policy configuration must be validated before accepted into the system. Inconsistent and conflicting rules may cause serious security breaches and network vulnerability, such as permitting unwanted traffic and blocking legitimate traffic. The order of rules must be carefully determined such that they don t create conflict. In this aspect, BaCon provides a mechanism for analyzing iptables and tc configurations to avoid four types of access-list conflicts discussed in [13-14]. If a new rule conflicts with previous rules, the system will alert users and will not accept the new rule. The second issue concerns the vulnerability of gaining root access to the system. Normally firewall and traffic control services require root privilege. By letting users manipulate iptables and tc control via a web interface, this means we grant system access right to user Apache. To prevent the Apache user from accessing unwanted services, we create a wrapper program to allow Apache to run just the necessary commands. In BaCon, Apache only needs to execute iptables commands, tc commands, and cron commands. So we create three wrapper programs, namely ipt.c, tc.c, and cron.c, shown in Figure 4. The wrapper programs will execute only if run as Apache user ID and the arguments have a proper format. User inputs are filtered for string literal escape characters such as.., /, or ; to avoid unexpected code injection attacks. For additional security, all web forms in BaCon implement the HTTP POST instead of HTTP GET method and avoid sending hidden-type inputs. Figure 4. Security model using wrapper D. Usability Considerations The key attribute that differentiates BaCon from other bandwidth management software is its usability. BaCon is designed to be as user friendly as possible although it would mean sacrificing some advanced bandwidth control functions. Because our target users are schools and small and medium organizations which usually lack dedicated network administrators, BaCon should be able to perform common tasks with just few clicks. Moreover, user input is designed to be as intuitive as possible (i.e., avoid technical terms). Error checking and input validation are also keys to avoid unintended configuration errors. Following items are some key usability design points of BaCon. BaCon provides multi-language support (English and Thai). BaCon provides status graph of current allocated bandwidth and free bandwidth. Users are not allowed to shape bandwidth more than the unallocated portion. For each rule, users only need to indicate incoming or outgoing direction for control. Users do not need to know which network interface to control. For each rule, users don t need to know exact port numbers or l7 filters for controlling popular applications. BaCon provides a pre-defined set of rule to choose from. If users would like to control traffic by port numbers, we provide a list of known ports for popular services. Users can select ports from this list without concerning whether to control TCP or UDP ports. (This concept is too advanced.) BaCon will block/shape both TCP and UDP ports by default. Users can enter many port numbers or a range of numbers together in one rule.

If users would like to control traffic using l7-filter, we provide a list of filter names, descriptions, and their quality for users to choose from. Users can choose multiple filters per rule. BaCon allows control of multiple services or multiple applications in one rule. This simplifies rule management. BaCon performs error checking on IP address format, valid port number range, and valid l7-filter names. BaCon works with existing firewall tools because BaCon sets up a separate iptables chain. The BaCon chain will be executed before other chains. BaCon alerts inconsistent and conflicting rules as described in Section III-C. BaCon offers scheduling capability which allows flexibility of control. For example, users can choose to activate a rule every certain hour-of-day, or certain dayof-week. There are three privilege levels for BaCon users: monitor only, monitor & control, and super user. E. Feature Comparison Table 1 compares features of BaCon against features of existing bandwidth management software like MasterShaper an IPCop. BaCon is developed to solve the features that deemed insufficient. It provides many types of report such as long-term traffic statistics, current allocated bandwidth, and CPU/memory usage, unlike MasterShaper which lacks these essential reports. Additionally, BaCon provides simple-tomanage firewall by offering pre-defined rules feature for inexperienced users. TABLE I. Features FEATURE COMPARISONS Master Shaper IPCop BaCon Long-term traffic statistics Current bandwidth allocation display Monitor bandwidth by rules and policies Manage groups of allocated bandwidth Report file (Excel/CVS) Report CPU/memory usage graph Action history log User friendly GUI Use l7-filter for shaping * Various graph report (line/pie/bar graphs) Pre-defined control rules Multi-language support Periodic scheduling of control rules * need special add-ons IV. PERFORMANCE EVALUATION This section validates performance of BaCon. Performance metrics of interest are bandwidth usage, CPU and memory utilization. Experiment setup consists of six personal computers: five local hosts and one Linux gateway (BaCon). All hosts are on the same broadcast LAN 100 Mbps, and connected to the Internet via eth1 (LAN connection). The eth0 is setup with a public IP address to connect WAN. We setup BaCon to do NAT (masquerading) and packet forwarding between the local hosts and the Internet. The setup is shown in Figure 5. Internet eth0 BaCon (tc_collector.pl) eth1 203.x.x.x 192.168.11.1 Figure 5. Experiment setup Local Network BaCon is installed on Linux kernel version 2.6.21. We patch the appropriate iptables version 1.3.8 to kernel. To support layer7 classifier, we patch iptables with l7-filter version 2.18. Finally, we install l7 protocal patterns version 2008-12-18. In this experiment, we want to evaluate the performance of BaCon. We subdivide bandwidth for web, bittorrent, and everything else via BaCon s web interface. We add two rules to control web traffic and bittorrent traffic. These rules are separated. For the web rule, we control traffic that match with port 80. For the bittorrent rule, we use BaCon s pre-defined bittorrent rule (control traffic that matches with porst 6881 to 6889, and packets classified as bittorrent by l7 classifier). This results in three sub-classes; two sub-classes for web and bittorrent, and another sub-class for other traffic. By default, we use HTB/SFQ to shape traffic. All classes have the same priority level. The traffic control tree is shown in Figure 6. 1:10, 1:20, 1:30 are the name of default, web, and bittorrent classes respectively. Figure 6. Traffic control tree for experiments A. Bandwidth Usage To test the performance of BaCon, we generated web and bittorrent traffic between internal and external hosts via BaCon. To generate web traffic and bittorrent traffic, we used wget [15] and utorrent [16] applications respectively. First, we added a rule to allocate 50 Mbps for web traffic via BaCon s web interface. While we were downloading file from server, we reduced the allowed rate for downloading web traffic from 50 Mbps to 10 Mbps at around 13:50. The average

download speed between 13:20 to 13:50 is 38.32 Mbps. The average download rate between 13:50 to 14:10 is 9.12 Mbps. The result shows that BaCon can shape web traffic as we intended to as shown in Figure 7. Next, we tested BaCon with bittorrent traffic. We added a new rule using the pre-defined feature to shape bittorrent traffic at 3 Mbps and reduced it to 1 Mbps at around 10:30. Figure 8 shows that BaCon can also shape bittorrent traffic accurately. In terms of system stability, BaCon has been set up as a gateway for seven clients in the Network Technology Lab, NECTEC. BaCon has been handling the total bandwidth of 100 Mbps during January- February 2008 with no instability problem. Figure 7. Bandwidth result after shaping web Figure 8. Bandwidth result after shaping bittorent B. CPU and Memory Utilization In this section, we evaluated the performance of CPU and memory utilizations. We generated traffic via BaCon, and recorded CPU and memory usage every five minutes. We performed this experiment during normal work hours for 8 hours (8.00 to 16.00). During this time, we set up rules to shape bittorrent, MSN messenger, and web at 1, 2, and 10 Mbps respectively, and let all seven users carry out normal Internet activities. We found that the average CPU and memory usages for the BaCon process are 0.35% and 0.39% respectively. The percentages of CPU idle process and free memory are shown in Figure 9 and Figure 10 respectively. Figure 9. Percentage of CPU idle process Figure 10. Percentage of memory free V. CONCLUSION AND FUTURE WORK In this paper, we present a user-friendly bandwidth controller called BaCon. BaCon is a Linux-based system for controlling bandwidth using iptables and tc utilities. BaCon is designed for inexperience users. It provides an easy-to-use web interface and wizards for creating new control rules. User can shape network traffic without understanding the complex control mechanisms and commands. BaCon provides both Excel and CVS format reports, and long-term statistics of past bandwidth usage suitable for SLA (service level agreement) reports. BaCon leverages strengths of iptables and l7-filter to achieve accurate traffic classification for various applications. In the future, we plan to improve security of the system by improving the performance of wrappers. We also plan to develop adaptive bandwidth control technique for a quantitative packet loss rate guarantee to aggregate traffic. Moreover, extensive testing to evaluate acceptable traffic load as a function of number of rules is required before real deployment. REFERENCES [1] Martin A. Brown, Traffic Control HOWTO, http://www.ibiblio.org/pub/linux/docs/howto/otherformats/pdf/traffic-control-howto.pdf [2] MasterShaper, http://www.mastershaper.org [3] WonderShaper, http://lartc.org/wondershaper [4] IPCop, http://www.ipcop.org [5] Netherlabs BV, Gregory Maxwell, Remco van Mook, Martijn van Oosterhout, and Paul B Schroeder, Advanced Routing Howto, http://www.linuxdocs.org/howtos/adv-routing-howto-11.html [6] l7-filter, l7-filter.sourceforge.net [7] ipp2p, www.ipp2p.org [8] RRDTool, http://oss.oetiker.ch/rrdtool [9] HTB, http://luxik.cdi.cz/~devik/qos/htb/ [10] SFQ, http://www.opalsoft.net/qos/ds-25.htm [11] http://www.plevna.f9.co.uk/blockchat.htm [12] http://compnetworking.about.com/od/bittorrent/qt/bittorrentports.htm [13] Ehab Al-Shaer and Hazem Hamed, Discovery of Policy Anomalies in Distributed Firewalls, IEEE Infocom 2004, Hong kong, March, 2004. [14] Ehab Al-Shaer and Hazem Hamed, Taxonomy of Conflicts in Network Security Policies, IEEE Communications Magazine, Issue: 3, Volume: 44, Pages: 134-141, March 2006. [15] wget, www.gnu.org/software/wget [16] utorrent, www.utorrent.com