I am very interested in your OS. What will be the minimum horsepower router on which it will run? If it would run on say a MT 450G, and the price was right, you'd sell a bunch! I'd buy several for my network.
An agnostic approach to bandwidth management is MY preferred way to deal with network congestion. If the pipe is getting clogged, look for long duration threads and delay those packets in deference to those short duration network transactions. Let the web pages load fast, let users retrieve email fast, but if there is congestion, take the headroom away from the bandwidth hogs until the congestion frees up. Addressing congestion in this manner, instead of spending hours and hours adjusting your network for the latest P2P or identifying the latest video delivery codec, will keep you out of trouble with any net police who might accuse you of targeting streams from a particular provider, or streams of a particular genre. All connections, from all users, to all sources will be treated with the same fairness rules. We currently have such a device running on our network that has made a dramatic difference in the dynamics of how our network operates. The device already exists. It's called a NetEqualizer. There are a couple things about the NetEq your OS will no doubt fix and add value to a net op. First, the NetEq is a core device. It examines connections, bandwidth usage and congestion. It polices the cumulative bandwidth, compares it to what you've set as the maximum pipe size, and does it's thing. The traffic still has to transit the wireless network to reach the core device. A separate appliance at every AP or cluster accomplishing the same thing would be a thing of beauty. There is no way we could afford a NetEq at every such point in the network, but if your OS will run on a lower cost device, I WOULD but one it at several points and actually keep on-air traffic managed better. The second place your OS would correct a shortcoming of NetEq is again moving it away from the core. At the core, every connection from a separate subnet, say from a distant tower deployment will look like they come from a single IP instead of from the many who might be using the tower. NetEq will still identify each thread as unique, UNLESS multiple users happen to be connected to the same distant IP address like Google, or MSN, or others. If the appliance were to be moved to the remote tower site, it could do its own "agnostic" conditioning of bandwidth BEFORE it gets on the backbone. So Butch, if there is good value in the system; its affordable, and will run on affordable hardware, and works well, count me in for several of them. I think, with those caveats addressed, you will sell scads of them on this list alone. As a rural WISP, with very high wholesale bandwidth expenses, placement of such devices on our network would indeed take us over the next hurdle which is no doubt coming. God Speed in your development and keep me posted. I'd even be a beta tester on a select repeater site. Regards, Mike At 10:44 PM 11/12/2009, Butch wrote: >... The fact is, that a GOOD bandwidth manager will >allow traffic to flow as fast as possible. One thing to bear in mind, >with regard to my QOS system, is that I don't speed limit ANYTHING. I >simply prioritize traffic so that the time sensitive stuff gets out >first. There is no reason to limit even P2P if there is available >bandwidth. Every class that I give that covers QOS, I restate this one >maxim: "QOS is not simply LIMITING bandwidth. Rather, QOS is about >MANAGING the available bandwidth resources." There is an important >distinction there that your comments don't take into account. > > > >We're thinking about how we're going to meet the demands of the near > > >future... not managing a shortage of bandwidth delivery. > >Even with sufficient bandwidth available, there are links and network >infrastructure where a good QOS mechanism will benefit the network. > > > >I'm thinking of planning on a future delivery of 4 to 6 meg per customer, > > >oversubscribed to around 4 to 6 to one. > >For many, 4:1 would mean out of business. Even at 10:1, many would not >survive. There are places in this country where bandwidth is still >quite expensive ($200/Meg would sound GOOD to some people). Even at >that price, a 4:1 ratio is $50/customer before you add in ANY costs. >Even 10:1 is to high. It would be NICE if the price for wholesale BW >came down, but too many folks do not have the benefit of reasonable >bandwidth. >-- >******************************************************************** >* Butch Evans * Professional Network Consultation* >* http://www.butchevans.com/ * Network Engineering * >* http://www.wispa.org/ * Wired or Wireless Networks * >* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * >******************************************************************** > > > >-------------------------------------------------------------------------------- >WISPA Wants You! Join today! >http://signup.wispa.org/ >-------------------------------------------------------------------------------- > >WISPA Wireless List: wireless@wispa.org > >Subscribe/Unsubscribe: >http://lists.wispa.org/mailman/listinfo/wireless > >Archives: http://lists.wispa.org/pipermail/wireless/ -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
