home user developer researcher download resource about


Here are the frequently asked questions and our answers. To pose a new question, please use this form.


hmm... but, we can control our traffic well enough with existing OSs. We don't need Netnice.

There have been a lot of implementations for traffic control on end-host operating systems; BSDs have ALTQ and Dummynet. Linux has Linux Advanced Routing and Traffic Control (LARTC). There are also a lot of firewall implementations; BSDs have ipfw and PF. Linux has Netfilter, and the Windows operating system has many personal firewall implementations. All of them can be regarded as mechanisms for end-host traffic control.

As reviewed above, each operating system has developed a variety of traffic control mechanisms, to meet its own needs and control goals, such as Quality of Service (QoS) and security.

Many people have asked us why we are developing Netnice, even if we already have so many implementations for traffic control. Our answer is fairly simple: it is because they are not perfect.


Almost all of the existing traffic control technologies are designed with a router-like packet classifier model, where administrators control flow of connections in the middle of the communications, based on information available on each packet such as IP addresses and port numbers (Figure 1). Since control of traffic has been done at routers (intermediate nodes) by administrators with appropriate authority, when the traffic control primitives such as queuing control mechanisms and packet filters were implemented on end-node operating systems, they have simply mimicked the router-model which was fairly useful to administrators. This conjuncture is partly supported by the fact that many hackers substituted SOHO routers by PC-Unix systems. Note that although most systems have extended their packet classifiers so that traffic is controlled by process ID or user ID, their model remains all the same: "authorized administrators govern traffic in the middle of communication".


This model is particularly useful for administrators to control traffic in the middle of communication. However, this model is fairly troublesome for end users and for control at the end-point of communication (Figure 2), as we state below.

First, these mechanisms are protected by privileged syscalls, and thus are only used by system administrators. On clients' systems, where a single user occupies one host, we may give the administrator privilege to the user. Nevertheless, in that case applications from the outside world, such as applets, will not be able to use the mechanisms to control their network I/O. It may behave gracefully but may consume the entire bandwidth available. We cannot tell what will happen. It is obvious that the mechanism cannot be used on multi-user systems for the same reason. These problems happen because the model does not include "resource protection" and "access control" between users, which are indispensable for end-host operating systems. We strongly believe that OS service needs to provide such features for end users.

Furthermore, each user has their own preference in resource utilization, such as access control, priority, and bandwidth for each application. These controls do not fit well with the traditional model for network control in the middle of communication, since these specifications are entities that terminate the communication.

Second, each application has its own way of utilizing resources and sometimes it needs to control its network I/O. Two examples are data transfer and streaming (Figure 3). Nevertheless, existing primitives are designed to control at intermediate nodes and they are not the best fit for applications terminating each communication.

For example, web servers may want to limit bandwidth usage of each virtual host and each user, or they may want to prioritize requests for important documents. However, to realize network control by the applications, we need mechanisms to control the resource utilization by the applications and access control features among the applications. Existing implementations do not support such features for resource management and access control (indispensable for programming freedom) and thus applications cannot control the resources allocated to them with a great controllability and flexible granularity. Even if we may grant administrative privilege for great controllability, this scheme will not work for untrusted programs, such as plug-ins, applets, and user-CGI. Clearly, on the current computer systems, traffic control by application programs has severe limitations.

Third, in most implementations, mechanisms for monitoring and statistics of traffic are separated from mechanisms for traffic control. For example, we cannot control traffic based on monitoring or statistics in a framework. Most firewall implementations do not allow users to inspect the traffic after filter rules are applied. Most of the implementations are designed for control by statically configured rules and thus dynamic control, such as feedback control, are partly realized only by combination of separated mechanisms. For example, we cannot easily realize such a control that monitors traffic integrity and lowers its priority (or limit bandwidth) based on the monitoring in a complete manner.

Finally, because most of the implementations are developed independently on each OS, these mechanisms are not compatible in nature. Although we have observed the surprising development of network applications, we still do not have a standardized API for a simple control, such as bandwidth control. Note that library-based approach does not solve the problem. For example, if we are trying to control the flow from outside the program, or to control a set of flows.

Control Targetdesigned for control at intermediate nodes with rules statically set by authorized administrators
Control by End-userSince the access is through privileged syscalls, end-users cannot use the mechanism without mechanisms like wrappers. Since there is no access control mechanism, we will have trouble with multiple user settings
Control by ApplicationSince there are no resource protection features, applications cannot easily enjoy the control mechanisms.
Completeness in controlMonitoring mechanisms and control mechanisms are independent.
CompatibilityCompatibility issue is mostly out of scope because the implementations are developed independently on each OS.
Traditional Model

As reviewed, current implementations are not free from flaws, even with their many years of "battle-proofing". In fact, the traditional model is for administrators who are working in the middle of communications, and this is not a desirable solution for end-host users and applications. Consequently, we are ignoring a variety of possibilities in end-host oriented network control. Netnice is designed as a core service of end-host operating systems, and can work as a complementary part to the traditional control model. We envision that the model works as a basis for future development of the end-host oriented network control technologies.

But, we can control the network per-process basis, by other implementations.

Yes, you can. There are many systems in which we can use process ID (PID) in the classification rule. Accordingly, users can simply use the feature for the per-process control. Please note that the point we are making here is not just a particular control granularity. rather, it is a fundamental flaw in the current control model, as we describe below.

For example, on a server system, we cannot grant the administrator privilege to users unless we have access control and resource protection among users. Even on a system with just one user, such as a client host, we cannot give such privilege to programs of unknown origin. A web browser cannot flexibly use the granted resource, to fairly share the resource among windows, or to grant some of the resource to their accommodating applet.


After all, the mainstream implementations have been developed as solutions to particular problems that most administrators encounter in daily operations, such as bandwidth control, queuing control, and packet filtering. They are definitely convenient and suitable for these problems. Thus, it is too natural that most of the administrators want to reuse the mechanism to deal with new situations and threats by extending its functionality.

Nevertheless, they are basically mechanisms for privileged administrators, and not designed for users and applications. We may satisfy some of their needs by wrapper mechanisms and other techniques, but we may still overlook a lot of cases and we overload the existing mechanisms. Examples include access control, resource protection, compatibility, and control granularity. Reusing the current model would obscure the important issues by providing somewhat defective solutions. We believe that this approach severely limits the various possibilities of end-host oriented network control.


Netnice has been approaching the problem, from the viewpoint of the design principle of end-host operating systems, considering fundamental properties needed for the service by the end-host operating systems. And, we identified that they need resource protection, access control, flexibility in control granularity, and dynamic controllability, contrary to network administration at the intermediate nodes, where the control model of the mainstream implementations come from, and concluded that the new control mode (hierarchical virtualization of network interfaces) could be a reasonable approach in the problem domain.

Alright. So, what are advantages of Netnice?

Major advantages include, but are not limited to, the following:


In Netnice-enhanced kernels, network interfaces are hierarchically virtualized as directories and files on a file system, and control of network I/O is made through file-control syscalls. Almost all the users and user applications can utilize the operating system service for network control. Access control between users are intuitively realized with file access permission. Note that the end-users do not need to care about this detail; they simply use control commands which hide the low-level API.

Application processes can create their own virtual network interfaces on top of the one they are originally attached to, and can utilize the interfaces for control of traffic at flexible granularity with great programming freedom on a unified model. Each hierarchical virtual network interface has parameters such as bandwidth, scheduling discipline, weight, priority, and packet filter, and applications can utilize all of the mechanism at their will. This realizes packet shaping, better utilization of bandwidth resource, and priority control. They can perform any operation safely because the resources are automatically protected by the inheritance mechanism of virtual network interfaces, which partitions each operation within a protected domain.

A hierarchical virtual network interface supports a variety of queuing control, traffic monitoring by libpcap, packet filtering, and packet diverting. The model integrates Quality of Service control and security control on end-hosts, and realizes feedback-based control at low cost. Further, we can easily extend the functionality of each virtual network interface.

Netnice was designed as a core service of end-host operating systems, and thus can be supported by most operating systems. We are making efforts to port the mechanism onto major operating systems, as reported elsewhere.

Control Targetdesigned for control at end-host by end users and applications, as well as administrators.
Control by End-userThrough the file-system API, end-users can easily enjoy the OS service. Access control is naturally realized with file-access semantics.
Control by ApplicationApplications can utilize a variety of controls at flexible granularity, while providing protection among applications.
Completeness in controlMonitoring mechanisms and control mechanisms are integrated into a framework, while keeping compatibility with BPF.
CompatibilityWe are porting the mechanism to major operating systems.
Hierarchical Virtual Interface Model

If Netnice is so neat, why is it minor??

Almost every end-host operating system has its own mechanisms for network control. Since they are developed to address realistic problems happening in the real world, they are quite usable for these problems. There would be little incentive to use a generic mechanism, such as the hierarchical virtual network interface.

Worse still, because we have just one implementation on FreeBSD, we cannot show its benefits as an OS-independent generic mechanism for network control. Consequently, we are having a dilemma that we cannot port the mechanism to various platform, because we support just one operating system now.

Last, but not least, there are technical dependency on the existing implementations and the model. However, it is a vicious circle if advancement of network control technology at end-host systems is limited by the dependency on the current architecture. Hence, we are trying to break the cycle by promoting the new control model, mainly developed in the research community, and to contribute toward sound growth of the network control technology.

Please evaludate this page.

Selection Vote
Excellent 6  
Good 4  
Fair 1  
Poor 0  
Horrible 0  

Any questions, or comments? Please fill in the form below! (Note that we may edit the questions and the comments for readability.)

Attach file: filecontrols.JPG 795 download [Information] filevifsystem.JPG 779 download [Information]

Reload   New Edit Unfreeze Diff Upload Copy Rename   Front page List of pages Search Recent changes Backup   Help   RSS of recent changes
Last-modified: 2011-07-25 (Mon) 10:31:43 (2428d)