Last October I started looking into purchasing a bandwidth management package for the College.   The goal was to provide better monitoring and control of the College's Internet bandwidth.  There were a lot of systems to choose from, but each had certain "fatal defects" that made it difficult to integrate into the campus network.  Here are a few of the more serious issues, and details on each:
 

Expense	Many systems were very expensive and required dedicated equipment, raising the overall cost even further, often to greater than $10,000.  For the capabilities I required, this was prohibitive.
Single Point Of Failure	All of the systems were implemented as, more or less, a dedicated box placed between the users / in-house servers and the Internet.  If the system were to fail, the users lose connectivity.  Similarly, a failure prevents external access to internal hosts.
Manageability	With few exceptions, none of the systems were directory enabled, neither using LDAP nor NDS.  As a result. for the system to be aware of users I would have to reproduce all the existing 2700 user account I already have in NDS.
IP Only	Most of the systems operated as a very smart layer 3 device, e.g. a router, which can only deal with TCP/IP traffic.  If you use other protocols the product was useless.
IP Sharing Issues	When using an IP sharing mechanism, such as the IP-IPX Gateway, the traffic shaping system sees only a single, very ravenous client, not the 200 workstations sharing the single IP address.  There is no way for the system to know that frame X is destined to workstation Y and so is completely ineffective in managing the bandwidth.
Slow	Some of the systems could only process T1 or 10Base-T speed traffic.  This is clearly not a "real world" situation any more as  typical backbone speeds of a LAN commonly exceed 100 Mbps.

After looking at about 5 products I got disgusted, after looking at another 5 I got angry.  The basic functionality I needed to reign in rampant IP-IPX gateway usage was nothing tremendously fantastic...  but lacking in each one! 

For several years I had been writing NLM's as a hobby. It "seemed" that it might be possible to write an NLM that managed the bandwidth passing though the server as well as traffic generated by it.  There were, however, several great technical challenges to getting this to work.

I "haven't quit my a day job," so the development effort has been rather limited by "free time" available at night.  The good news, sort of, is that I have insomnia frequently.  So instead of watching Gilligan's Island reruns I get busy with the compiler. 

After about two months I had some decent code that implemented some very rudimentary functionality - though pretty limited and in a very large test harness.  But this original code, which evolved into the Traffic Shaping Engine, the TSE, provides much of the functionality required.  The rest of the time has been devoted to expanding the ability to control and configure the TSE.

The core code of the TSE that interacts with the OS to intercept network traffic has remained pretty much unchanged since January and has been operating at 500 to 1000 frames a second on test servers continuously since then.  Two of these servers had over 140 days of up time each,  running the code until a power outage rebooted them.  I have also stress tested the code by pumping over 5000 frames a second through it - with only a 10% cpu load!  So far the TSE code had processed over 20 billion frames in the test bed without a problem.