Thanks Tom for the information. I appreciate you taking the time our of your busy day to give me such good information. It is greatly appreciated. I will make some adjustment to increase cpe bandwidth and see what happens. Most of my traffic shoul be bursty because it is business but I do have a few people that stream HD video (around 3mb stream) that I will probably leave.
Sent from my iPhone On May 20, 2010, at 10:21 AM, "Tom DeReggi" <[email protected]> wrote: > That depends on how long your peaks last. > > The bottom line is that peaks generally only last short periods. If > you run > out of peak capacity, the side effect is usually minimal. All that > occurs is > that transfers during those peak time slow down a bit and spreadout > over a > longer period of time. TCP in nature handles this for you > automatically. > The longer you hold off on upgrading, (meaning increasing average > usage) The > usage graph starts to flatten out, with less distance between > average and > peak. If you have a large number of subs on a backbone, that may not > have > much of a negative effect on the users at all. Remember most people > cant > tell the difference between 1mb and 2mb without running a speed > test. For > this reason, I care very little about peak usage stats. > > What is way more relevant is "average usage". I personally think when > average usage is around 50%, its time to think about upgrading, and > when > average usage exceeds 70%, you are way overdue > How much you push the limits and how quickly you move to upgrade is > determined on several factors. > > 1) How long it will take to deliver an upgraded pipe. If its 6 > months, think > ahead. If its 1 week, you might be able to wait till users start to > complain. > > 2) Your SLA. If you have a bunch of high ARPU customers with SLA, > you may > want to upgrade sooner. For example, if you sell 100mb end user > pipe, where > custoemr may not use it much, so oversubscription can be > significant, but > the customer pays a lot to make sure 100mbps is available when they > send > their large docs once a week. Where as if selling best effort end user > services, does it really matter if they slow down during peak usage > hours? > > 3) What you charge. There is a reality to market price and costs. > If your > selling price is low enough, and your costs are high enough, you > may not > have any choice but to attempt to change end user's usage patterns. > For > example, if average bandwdith gets to high, the answer may be to start > blocking or slowing down certain types of services, to discourage > end users > from performing those functions. For $19.95 do you allow then to > stream > NetFlix, or do you change your AUP and firewall to fix it? The > first thing > we always ask is.... Why is the bandwidth usage so high? For > example, have > you checked how much inbound bandwdith is from Internet born DOS, > SPAM, > Spyware, Scanning, etc? OR what about network overhead? Whether to > roue > versus bridge, VLAN or not VLAN, Monitor end-to-end centrally versus > distributed local monitoring, all have a factor on bandwidth usage. > > A more relevent question might be... How much bandwdith per user > should be > allocated on a backbone, for healthy operation and profitabilty of > the WISP? > That number may depend on how Internet savy the commuity base is, or > cost > structures of that market. My point here is that the decission on > backbone > bandwdith may not be a technical decission. And if its technical, the > solution may not always be to add bandwdith, and the anser might be > to stop > wasting bandwidth. > > But from a technical perspective there are realities that need to be > addressed. There becomes a time when action must be taken in some > capacity. > > Most importantly let me point out an example regarding the effect of > peak > usage and why it is not bad. Set bandwdith management to heavilly > restrict > bandwdith. For example, set a CIR to 512k and MIR to 1mb. You will > see low > peak usage, and a lot of bandwidth being wasted, meaning you can > never go > back in time to recover unused badnwdith. Now set CIR to512, and MIR > to > 10mbps. You will see peak usage skyrocket for short periods, but the > average > usage will go way down, because users use the network for short > periods, and > IF there is any unused bandwdith they are free to use it, before the > opportunity in time is lost to do so. The mentality if always free the > network up for the next guy as soon as possible. Operating a network > in that > way (high MIRs) can easilly double the amount of capacity that can be > aggreegated accross a backbone. In many cases, all you have to do to > prevent bandwdith shortage, is just to INCREASE your customer's > configured > peak speed. If there usage need stays the same, you will waste less > bandwdith and more efficiently use the network. > > The other thing is it may matter what type backbone you have. For > example, a > PTP network can use a Ethernet segment very effectively, probably up > to > close to 85-90%. But on a Multi-user segment like an office LAN, > Ethernet > capacity will saterate at about 50% because of collision avoidance > issues. > If you are agreegating multiple feeds into a backbone, whether the > data fed > into it collides with other data fed into it may depend on the > bandwidth > management methods and switching technology. IF the network is not > always > available, it can cause retransmits or higher latency, and that can > effect > end user's experience. So again, whether 50% or 80% backbone usage is > acceptable may depend on many factors in your network design. > > Remember a network is only as fast as its weakest link, and a > saturated > backbone closest to the Intenet will have an effect on all links > inline > prior to on the way to the customer. IF bottle necks are reached, > end user > speed slows down. (as long as capacity is free outside of peak). > Packet loss > and high latency WONT occur much until capacity is saturated to > often during > average usage (considering TCP, UDP is different). When you end user > 1mb > circuit is averaging 100mbps, How do you know if its because low > customer > usage/activity, or because bottlenecks are incurred somewhere > inline? And > how important is it to you, for that customer to have better than > 100kb > speed? How drastic is the spread between peak usage and average. > Many what > percentage of your daily network usage occurs at a reasonable window > around > that peak period? Short peaks and a long peaks can have much different > effects on end user's experience. But whats important is that > measuring > backbone bandwdith usage may not give you enough data to know when to > upgrade. You will also want to measure average packetloss and > latency. You > might find that the time to upgrade might be better determined when > average > latency exceeds a specific threshold. And the feedback from > subscribers may > also be important. > > Also note, there are many different meaning to "average" and how it is > calculated. There is a reason that many bandwdith sellers use the > 95%tile > algorythm. To remove the highest and lowest 5%, for the data to be > more > meaningful. (or something like that). > > But.... in summary, without all the factors to consider.... start > considering upgrading when "average" usage exceeds 50%, and you'll > be plenty > safe, and you'll still have some flexibility to wait longer if you > need to. > > Tom DeReggi > RapidDSL & Wireless, Inc > IntAirNet- Fixed Wireless Broadband > > On Thu, May 20, 2010 at 9:09 AM, Jeremie Chism <[email protected]> > wrote: >> At what percentage of your backbone usage do you look at adding more >> capacity. At peak times I run at 65-70 percent of capacity. Just >> looking for suggestions. >> >> Sent from my iPhone >> >> >> --- >> --- >> --- >> --- >> -------------------------------------------------------------------- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> --- >> --- >> --- >> --- >> -------------------------------------------------------------------- >> >> WISPA Wireless List: [email protected] >> >> 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: [email protected] > > 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: [email protected] > > 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: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
