Date: Wed, 23 Jun 2004 20:46:50 -0400 From: Takashi Okumura <taka@cs.pitt.edu> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket Message-ID: <40DA247A.BE7213FB@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>
next in thread | previous in thread | raw e-mail | index | archive | help
hi, Brooks Davis wrote: > > I think netnice looks really neat. > > Use of /proc would definaly limit the utility of integrating the code. > We don't enable procfs by default because it's too hard to get procfs > code right as the list of procfs security advisories demonstrates (not > just on FreeBSD, but Linux, Solaris, etc.). > thanks for the comment. yes, it seems that it is a bit hard to keep the original procfs interface intact, when we port the mechanism on to other platforms. probably, we'll need a library, libnetnice, which absorbs the details of the low-level API... *** *** *** btw, honestly speaking, we are feeling that there are two types of responses when we present the new model for end-host network control. one is that it is simply useful. this is true, particularly for applications and for end-users, because the VIF model realizes flexible granularity and many advanced features for user applications, while providing resource protection and access control between users on an end-host. the other type of response is that it is simply useless. this is because we already have dummynet, ALTQ, PF, BPF, and other useful implementations. i understand this response, since their control model (based on packet classification) has been used for years by network administrators and is intuitive. further, they have many years battle-proof, which what we lack. actually, my first netnice implementation greatly owes to Luigi's work, and personally, i'm quite thankful to him. but, basically, these existing mechanisms are protected by privileged syscalls, and does not possess mechanism for resource protection nor access control, which is needed to release API to users on end hosts. so, probably they are for administration purpose of router-like host, not for use by user applications. so, my point is that we are addressing different problems, and what i'm pursuing is "coexistence" of the implementations, targeting towards different situations. but, my current concern is that we have not provided enough information about our project; why we needed such a new model, its advantage and disadvantage, how to develop netnice applications (easy guide of the API for application programming), catalog of various VIF types, etc. this is because, although i've been writing papers in english, these useful information is available mostly just in Japanese... so, if you know any japanese friend, or if there are japanese-speaking subscriber in the mailing list, we would really appreciate your help. (we may even support the activities financially, this year). that way, we would be able to provide the community much more information about our efforts. if the topic is beyond scope of the ML, i sincerely apologize for the inappropriateness, and may move to our sf.net BBS, or to netnice developer's ML. http://sourceforge.net/projects/netnice/ i would appreciate any suggestions, comments, feedback, etc. thanks! -- taka
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40DA247A.BE7213FB>