Date: Thu, 24 Jun 2004 20:02:14 -0400 From: Takashi Okumura <taka@cs.pitt.edu> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket Message-ID: <40DB6B86.EFB4611E@cs.pitt.edu> References: <40D8FF41.6392C8F7@cs.pitt.edu> <1087973537.32330.58.camel@localhost> <40D92F33.7B54B5C4@cs.pitt.edu> <20040623150955.GA15320@Odin.AC.HMC.Edu> <40DA247A.BE7213FB@cs.pitt.edu> <40DB5737.36CBB21E@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
hello, Andre Oppermann wrote: > > > i would appreciate any suggestions, comments, feedback, etc. > > I haven't looked at the code. Although my question is why do you use > the proc interface? Can't you make netnice use the socket options > interface to configure the bandwidth limiting? Honestly I think this > would be much more natural for the task at hand (limiting connections > from the application). your question is natural, and i understand your position. for simple bandwidth limiting control, library-based approach would be the best solution, because of its portability, simpler API, and easy implementation :-) but, this approach is fairly restrictive, and limiting the way we control the network I/O. that is our position, and i state why. First, what we need is not just a bandwidth limitter. For example, we may have a server process (or processes), which accommodates several connections, one for control and others for data transfer. it is quite reasonable to give higher priority to the control traffic, while providing fair queuing to the connections for data transfer. And, then, we might also need to limit the bandwidth of the entire activity (this is how mod_netnice works, actually). Implication of the case is that application programs, and end-users, need a variety of options for the control of their network I/O. We call this as a need for "control freedom" by applications. Second, as the case suggests, granularity of the control needs to be flexible. it is definitely reasonable to have a control primitive that works on a flow. but, we also need a mechanism with which we can control a set of flows. for example, we may want to give 4Mbps to 4 connections. the extension of socket interface cannot provide this flexibility in the granularity. this is also required for work-conserving scheduling, such as weighted fair queuing and priority queuing. OS service for network control needs to posses flexible granularity in its control. Third, we may use a library for bandwidth limiting for programming, but, if we are satisfied with the library-based approach, utilization of network control is limited just to trusted applications. for example, applications from outside world, such as applet, will not be able to control its network I/O. it may consume the entire bandwidth available, or, may behave gracefully. we can't tell what happens. So, we believe that OS service needs to provide "resource protection" so that applications can have a full control of the resource, conforming to the limit granted. In this case, by providing resource protection feature, we can give, say, 4Mbps, to a program, and the program can utilize the resource for any kind of control, not limited just to control of bandwidth, as i described above. Lastly, such a mechanism for resource management needs access control feature. otherwise, an user on a system may preempt some resource granted to another user, or application. To realize such freedom in network control, we proposed "hierarchical virtual network interface; VIF" model, as a service for network control by end-host operating systems. And, (here is my conclusion, of the long story. sorry!) we used the file system abstraction, to represent the hierarchical nature of the VIFs. This interface also provides intuitive semantics for access control between users; my VIF is accessible only by me, or by root. so, the scope of the interface is a bit broader than just the bandwidth limiting in our proposal. if you are interested in a bit more detail, this (http://www.cs.pitt.edu/~taka/tc.pdf) might be helpful. it's the only document currently available that describes the entire concept, in english. i should have provided such information, hopefully on the web. but, due to the problem i mentioned in the last message, we're currently overloaded, so... anyway. sorry for the long message, again. i just wanted to avoid flaming due to mutual misunderstanding, since it is based on a bit different concept from other implementations. again, i appreciate the current control model, which is definitely useful. i also appreciate the library based approach, which can be much smarter solution, depending on the goal of the control. thanks! -- taka
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40DB6B86.EFB4611E>