home user developer researcher download resource about



This page shows API overview of traffic control based on hierarchical virtual network interface. Target of this document is application developers.

Currently, we are working on a library to wrap API detail. But, until we complete its specification (or, for some advanced developers), we need to use a low-level API to control the VIF.

Don't worry! It's quite simple. If you know the basic knowledge of file operations, such as open(), close(), read() and write(). In fact, we do not require any particular developing environment or language.

Review of the VIF based network control

As reviewed elsewhere, we can cascade the hierarchical virtual network interfaces (VIF) into multistage on top of the physical network interfaces. These VIFs can be attached to sockets, to processes, and to process group so that they are used to control network I/O of the terminating entities, realizing flexible control granularity with resource partitioning.

In addition, we can set various parameters of a hierarchical virtual network interface, such as bandwidth, queuing mode, weight, and priority, to realize a variety of traffic control, such as packet shaping, Weighted Fair Queuing, and Priority Queuing, in a unified manner.

We would briefly illustrate how we control the VIFs, with the file system application programming interface (API).

the Procfs API

A sample case

First, we show a sample case of VIF based traffic control, below.


There are two daemon processes (p1 and p2) for network file system access. Suppose that they are mounting a file server on the local network and have bursty traffic pattern (e.g., file transfers). On the right, there is a Web browser process (p3), accommodating several threads, and one of them is reserved for data streaming. Note that bursty traffic occasionally saturates the real network interface and starves the web browser process flows, by the network file system.

Our goal is to give proper protection to the processes and provide a better quality of service to our system users. To this end, we show below how to configure the VIFs. First, we reserve certain amount of bandwidths for the streaming application. This can be achieved by limiting the file system traffic. thus, we configure the flow specification of VIF 3 so that the bursty traffic is bound, by some predefined bandwidth (e.g., 4Mbps). Next, we give fair shares to the file system processes for better utilization of the limited bandwidth. For instance, 50 percent of VIF 3 to each VIF 1 and VIF 2. VIF 4 and VIF 5 are for Web browsing. Assume that VIF 4 is for the streaming and VIF 5 for TCP connections. Again, to assure the streaming quality, it would be better off limiting the bandwidth usage of VIF 5, and leaving room for VIF 4 to receive the time-sensitive data.

Now, how can we realize such control on the netnice kernel?

File System representation

On Netnice kernel, the system abstract all the VIFs and their control as directories and files on a file system and their access operations. To illustrate the abstraction strategy, below is a sample directory representation for the above VIF configuration.


A directory under /proc/network/ represents a VIF. The root VIF is named as fxp0, which corresponds to the name of a real network interface on the machine, marked as interface 6 in the original figure. The VIF has three VIFs under it; VIF 3, VIF 4, and VIF 5. Files under a VIF (e.g., bandwidth and stat) contain configuration parameters for the virtual interface (for simplicity, only some of them are shown in the figure).

Directories under /proc/[pid]/ are process entries. We added a sockets directory under each process entry. As shown, process 1 (p1) and process 2 (p2) have one socket each and process 3 (p3) has two sockets. Directory names (such as 1 and 2) for the sockets correspond to the file descriptors they are assigned to. Under each individual socket directory there is a link named fxp0 (e.g., directory /proc/[p3]/sockets/1/ fxp0/), indicated by "@" in Unix convention. The links denote attachment of the VIFs to the particular resources. For example, p3 has its network I/O capped by a VIF represented as /proc/ network/fxp0/ and the two sockets of p3 are connected to VIF 4 and VIF 5.

The association of a VIF and an OS-supported entity (e.g., a process or a socket) is represented by a link that has the same name as the real interface (in this case, fxp0). This convention is chosen because we may have several network interfaces, like fxp0 and fxp1. (We will revisit this multiple interface issue later.)

In summary, there is a directory for configuration of the VIF structure. And, each process entry possesses a sockets subdirectory for VIF association. Under that directory are subdirectories for each socket and software links pointing to their respective target VIFs.


The file system based abstraction is quite powerful for the following reasons.

First, protection model of the system automatically realizes access control semantics of underlying file system. This access control enables the control of network I/O by normal users, as well as by system administrators, within a protected domain.

Second, object oriented operation on a hierarchical virtual network interface is realized, by the reuse of existing file access mechanism. This feature favors control of network I/O by environment where system call, or object oriented data structure, is not supported.

Third, the hierarchical structure of the hierarchically virtualized network interfaces is expressed in an intuitive manner by the structuring of directories. System call based API, alternative interface of the system, can not provide this ease. Utilizing the file system abstraction, we can access a variety of system features with ordinary tools for file operation.

Fourth, this abstraction does not specify the behavior of the VIF based control, but, it simply specifies a general rule of the system interface: To read a parameter, read the parameter file. To set a parameter, simply write to the parameter file. Accordingly, we can utilize many types of VIFs with a unified interface, while preserving a great room for functional extension.

Finally, this abstraction can realize control of network I/O of any entity on the operating system, as long as it is expressed on procfs, such as thread and sockets.

Related Pages

Attach file: filefig2.bmp 1177 download [Information] filefig1.bmp 1279 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: 2010-04-25 (Sun) 08:51:33 (2884d)