Re: [WISPA] Advanced Bandwidth Management
Do any of you use caching to save on bandwidth consumption? Blair Davis wrote: The other point is, that with a good mix of residential and business customers, and a little creative thinking, one can match their usage patterns to minimize ones peak bandwidth requirements while still providing the 'fast, snappy feel' that the users prefer -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
This will get harder as 4Q07 approaches and ATT rolls out it's $10 DSL and $19.95 Naked DSL - as per merger concessions. There will be a ton of disqualifiers. However, this will effectively put many Residential ISPs in the NFL cities out of business. I don't understand the race to the bottom. But I do understand the numbers game. Cheaper means easier to sign up more subs. Maybe selling metered internet like the cellular guys do with EVDO would be a smarter model. Or a bandwidth cap. Regards, Peter Radizeski RAD-INFO, Inc. (813) 963-5884 Travis Johnson wrote: OR, we could stop playing the Cable Co. and Telco games with their up to 3meg and up to 7meg connections for $34.95 and just start selling what they get. We started selling 512k, 1meg, 1.5meg and 2meg connections (up and down, guaranteed speed 24x7) about 3 years ago. It was the best thing we ever did... people get what they pay for, and when they need more, they buy more. No games, no burstable speeds, etc. Make your customers pay for what they need and use. Travis Microserv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
But we can;t forget about delivery! Anyone can create a price sheet, but can they deliver? The day the competors delivers 10 meg for $10 per month, and consistently delviers to the majority of the population, it will be past the time to look into being in another business. But I'm betting on the fact that they won't get there as fast as they advertise, at the quality level customers demand.. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Peter R. [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Thursday, January 25, 2007 8:18 AM Subject: Re: [WISPA] Advanced Bandwidth Management This will get harder as 4Q07 approaches and ATT rolls out it's $10 DSL and $19.95 Naked DSL - as per merger concessions. There will be a ton of disqualifiers. However, this will effectively put many Residential ISPs in the NFL cities out of business. I don't understand the race to the bottom. But I do understand the numbers game. Cheaper means easier to sign up more subs. Maybe selling metered internet like the cellular guys do with EVDO would be a smarter model. Or a bandwidth cap. Regards, Peter Radizeski RAD-INFO, Inc. (813) 963-5884 Travis Johnson wrote: OR, we could stop playing the Cable Co. and Telco games with their up to 3meg and up to 7meg connections for $34.95 and just start selling what they get. We started selling 512k, 1meg, 1.5meg and 2meg connections (up and down, guaranteed speed 24x7) about 3 years ago. It was the best thing we ever did... people get what they pay for, and when they need more, they buy more. No games, no burstable speeds, etc. Make your customers pay for what they need and use. Travis Microserv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
Yeppers, one size does not fit all. Out here, I have customers that get 30 meg for $50 per month. I also have customers that pay $350 for 6 megs. We don't bill for speed out here though. Everyone gets to go as fast as I can make them go. I bill per bit. MOST of our customers get REALLY cheap REALLY fast internet. The ones that actually USE it are the ones that pay for it. I don't bandwidth shape anything other than the ptp programs. I don't much care what people do on the net as long as they pay for it We're just enforcing the program now. We've lost a couple of users but mostly we're getting people to pay much more than they did before. $75 business accounts will end up paying $100 to $150 (in one case $350). Some home users will move from $35 to $50 to $100. AND our costs are already trending down a bit. The best part? Now our competitors have to upgrade their systems and pay more for bandwidth to deal with the folks that want something for nothing and will move from us to them even though we're faster. And the customers that are left here will get even better service! laters, Marlon (509) 982-2181 Equipment sales (408) 907-6910 (Vonage)Consulting services 42846865 (icq)And I run my own wisp! [EMAIL PROTECTED] www.odessaoffice.com/wireless www.odessaoffice.com/marlon/cam - Original Message - From: Blair Davis [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, January 24, 2007 2:21 PM Subject: Re: [WISPA] Advanced Bandwidth Management We sell mainly to residential users and to some small businesses. We are quite rural, and my cost for a T-1 is $450 per month. My pending fiber hookup is $1100 per month for 5Mbit. A bit ago, a business customer's new IT consultant complained that the 256Kbit committed rate for $60 a month was over priced. He demanded a 1Mbit committed rate and no price change. I explained this was not possible. He was quite nasty and told me he was recommending that the customer find a new ISP. I, fed up with his big city attitude, told him to go right ahead. He said to come pick up the gear on this Friday. Although, I might have lost my temper a bit and used some words that the FCC doesn't permit on the phone.. After he was quoted $600 per month for a T1, (and $9500 install), and a 3 month lead time, he called me back... He decided that my offer of 1Mbit committed rate (6am-6pm, Mon-Fri) and a 256Kbit committed rate at other times) for $250 a month was a damn good deal.. The point of this, is that, for many customers, pricing and bandwidth expectations are being driven by the cheap bandwidth in the large cites Out here in the real world, it don't work that way. The other point is, that with a good mix of residential and business customers, and a little creative thinking, one can match their usage patterns to minimize ones peak bandwidth requirements while still providing the 'fast, snappy feel' that the users prefer Just my $.02 J. Vogel wrote: I would suspect that the customer (as is the case in much of the world, not necessarily in the limited world you may operate in) does not want to, or in many case could not pay for such a pipe. In many areas of the US, especially rural, bandwidth is extremely expensive. Customers do not want to pay close to $1k / month for their residential connection to the internet, yet the customer would like to access the internet at speed approaching 1.5 mbps (or even faster) whenever they can. In such a case it makes sense, is good business practice, and not at all unethical to sell customers shared bandwidth. In cases such as these, the question posed by the OP is a valid question, and deserves an answer other than one which implies that they may be doing something they should not be. The world is a big place. It is good to get out and see parts of it you may not have seen lately. John Matt Liotta wrote: Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt -- Blair Davis AOL IM Screen Name -- Theory240 West Michigan Wireless ISP 269-686-8648 A division of: Camp Communication Services, INC -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
I do. I run a squid cache (that way filtering comes easy too). I get a hit rate of 40% (40% of requested items come from the cache), and this accounts for 20% of the bandwidth (the 40% are usually small graphics, etc). So I stretch my bandwidth by about 20%. Jason Peter R. wrote: Do any of you use caching to save on bandwidth consumption? Blair Davis wrote: The other point is, that with a good mix of residential and business customers, and a little creative thinking, one can match their usage patterns to minimize ones peak bandwidth requirements while still providing the 'fast, snappy feel' that the users prefer -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
Wow! Thanks much. So linux bandwidth management implements the Token Bucket Algorithm in its queue controls, which is similar to, but not the same as the Leaky Bucket Algorithm I'm familiar with. I'm trying to understand the subtle diference, but it'll take some time: Now that I've read about the Token Bucket Algorithm from the Linux URL you provided, I've found a source that contrasts them (shamelessly, it's wikipedia!): Two predominant methods for shaping traffic exist: a leaky bucket implementation and a token bucket implementation. Sometimes the leaky bucket and token bucket algorithms are mistakenly lumped together under the same name. Both these schemes have distinct properties and are used for distinct purposes [1]. They differ principally in that the leaky bucket imposes a hard limit on the data transmission rate, whereas the token bucket allows a certain amount of burstiness while imposing a limit on the average data transmission rate. I can't say I understand the difference yet, but I'm motivated. Does anyone else understand or know how to explain the difference? Rich - Original Message - From: Ryan Langseth To: WISPA General List Sent: Thursday, January 25, 2007 12:44 AM Subject: Re: [WISPA] Advanced Bandwidth Management On Jan 24, 2007, at 8:25 PM, Rich Comroe wrote: Thanks much. I love it when you talk technical! Sorry, couldn't help it... No really, the devil is always in the details in these things. This is just the detail I was looking for. After I digest I hope I may send questions your way off-list. Still hoping operators using other brands will share what bw management algorithms they may have built-in. If you are looking for a better understanding of some of the traffic control systems, the Linux Advanced Routing and Traffic Control manual is a good place to look. Starting at chapter 9, it goes into some detail on how some of the the algorithms available work and how to implement them. http://lartc.org http://lartc.org/howto/lartc.qdisc.html thanks again, Rich -Ryan -- InvisiMax Ryan Langseth Systems Administrator [EMAIL PROTECTED] work: (218) 745-6030 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
Great reference and I've learned a tremendous amount from this list. I learned that I have been mis-using the term Leaky Bucket. I now understand that what Jason described to the list is Token Bucket (I was totally wet in my earlier reply calling it Leaky Bucket). Radios that implement bw management vary considerably in sophistication of their bw management algorithms. I'm really impressed with the Alvarion bw management. Canopy has bw management built-in as well, but it seems less sophisticated. I'm also impressed with what I've learned Linux advanced bw management can do at the head-end if your radios don't. Given radios can be bridged or not, bw management in the in-radio implementations seem better ... because I don't see how head-end bw management can distinguish between bw to multiple destinations behind the same customer radio if the radios are bridged. Even if the radios are not bridged, then I'd see in-radio bw management as 'still' better because bw limited at the customer radio doesn't chew up inbound rf capacity, while in head-end bw management the rf inbound capacity gets burned whether the traffic is ultimately limited or not. Anyways, I'm getting a great deal from the discussion, and would love to hear if other radios have built-in bw management and what method is use for comparison (any Trango users who could possibly comment?). Rich From: Ryan Langseth To: WISPA General List Sent: Thursday, January 25, 2007 12:44 AM Subject: Re: [WISPA] Advanced Bandwidth Management On Jan 24, 2007, at 8:25 PM, Rich Comroe wrote: Thanks much. I love it when you talk technical! Sorry, couldn't help it... No really, the devil is always in the details in these things. This is just the detail I was looking for. After I digest I hope I may send questions your way off-list. Still hoping operators using other brands will share what bw management algorithms they may have built-in. If you are looking for a better understanding of some of the traffic control systems, the Linux Advanced Routing and Traffic Control manual is a good place to look. Starting at chapter 9, it goes into some detail on how some of the the algorithms available work and how to implement them. http://lartc.org http://lartc.org/howto/lartc.qdisc.html thanks again, Rich -Ryan -- InvisiMax Ryan Langseth Systems Administrator [EMAIL PROTECTED] work: (218) 745-6030 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
From what I understand, there are many types of qdisc (HTB, CBQ, Prio, on and on) that you can invoke with the 'tc' linux command. HTB is the 'Hierarchical Token Bucket' that you hear a lot about because it works well. HTB should not be confused with 'Hierarchical TOLKIEN Bucket' that has something to do with the Lord of the Rings. 'Leaky Bucket' is a reference to my brains as I try to grasp bandwidth shaping. Jason Rich Comroe wrote: Great reference and I've learned a tremendous amount from this list. I learned that I have been mis-using the term Leaky Bucket. I now understand that what Jason described to the list is Token Bucket (I was totally wet in my earlier reply calling it Leaky Bucket). Radios that implement bw management vary considerably in sophistication of their bw management algorithms. I'm really impressed with the Alvarion bw management. Canopy has bw management built-in as well, but it seems less sophisticated. I'm also impressed with what I've learned Linux advanced bw management can do at the head-end if your radios don't. Given radios can be bridged or not, bw management in the in-radio implementations seem better ... because I don't see how head-end bw management can distinguish between bw to multiple destinations behind the same customer radio if the radios are bridged. Even if the radios are not bridged, then I'd see in-radio bw management as 'still' better because bw limited at the customer radio doesn't chew up inbound rf capacity, while in head-end bw management the rf inbound capacity gets burned whether the traffic is ultimately limited or not. Anyways, I'm getting a great deal from the discussion, and would love to hear if other radios have built-in bw management and what method is use for comparison (any Trango users who could possibly comment?). Rich From: Ryan Langseth To: WISPA General List Sent: Thursday, January 25, 2007 12:44 AM Subject: Re: [WISPA] Advanced Bandwidth Management On Jan 24, 2007, at 8:25 PM, Rich Comroe wrote: Thanks much. I love it when you talk technical! Sorry, couldn't help it... No really, the devil is always in the details in these things. This is just the detail I was looking for. After I digest I hope I may send questions your way off-list. Still hoping operators using other brands will share what bw management algorithms they may have built-in. If you are looking for a better understanding of some of the traffic control systems, the Linux Advanced Routing and Traffic Control manual is a good place to look. Starting at chapter 9, it goes into some detail on how some of the the algorithms available work and how to implement them. http://lartc.org http://lartc.org/howto/lartc.qdisc.html thanks again, Rich -Ryan -- InvisiMax Ryan Langseth Systems Administrator [EMAIL PROTECTED] work: (218) 745-6030 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
My precious! It further occurs to me that even if you have radio built-in bw management you would also be pretty smart to have bw management enabled at the head-end, too. Why? Radio built-in bw management will block customer excess rate inbound customer traffic from wasting your rf capacity between CPE Access Point, but if you've got rf backhaul to the site you need head-end bw management as well to block excess rate outbound customer traffic from wasting the rf backhaul bw before it ever reaches the AP's outbound bw management. And the outbound bw is typically greater than the inbound bw anyway. So it now looks prudent to me to have BOTH bw management built into the radios, AND at the head-end. Rich - Original Message - From: Jason To: WISPA General List Sent: Thursday, January 25, 2007 2:31 PM Subject: Re: [WISPA] Advanced Bandwidth Management From what I understand, there are many types of qdisc (HTB, CBQ, Prio, on and on) that you can invoke with the 'tc' linux command. HTB is the 'Hierarchical Token Bucket' that you hear a lot about because it works well. HTB should not be confused with 'Hierarchical TOLKIEN Bucket' that has something to do with the Lord of the Rings. 'Leaky Bucket' is a reference to my brains as I try to grasp bandwidth shaping. Jason Rich Comroe wrote: Great reference and I've learned a tremendous amount from this list. I learned that I have been mis-using the term Leaky Bucket. I now understand that what Jason described to the list is Token Bucket (I was totally wet in my earlier reply calling it Leaky Bucket). Radios that implement bw management vary considerably in sophistication of their bw management algorithms. I'm really impressed with the Alvarion bw management. Canopy has bw management built-in as well, but it seems less sophisticated. I'm also impressed with what I've learned Linux advanced bw management can do at the head-end if your radios don't. Given radios can be bridged or not, bw management in the in-radio implementations seem better ... because I don't see how head-end bw management can distinguish between bw to multiple destinations behind the same customer radio if the radios are bridged. Even if the radios are not bridged, then I'd see in-radio bw management as 'still' better because bw limited at the customer radio doesn't chew up inbound rf capacity, while in head-end bw management the rf inbound capacity gets burned whether the traffic is ultimately limited or not. Anyways, I'm getting a great deal from the discussion, and would love to hear if other radios have built-in bw management and what method is use for comparison (any Trango users who could possibly comment?). Rich From: Ryan Langseth To: WISPA General List Sent: Thursday, January 25, 2007 12:44 AM Subject: Re: [WISPA] Advanced Bandwidth Management On Jan 24, 2007, at 8:25 PM, Rich Comroe wrote: Thanks much. I love it when you talk technical! Sorry, couldn't help it... No really, the devil is always in the details in these things. This is just the detail I was looking for. After I digest I hope I may send questions your way off-list. Still hoping operators using other brands will share what bw management algorithms they may have built-in. If you are looking for a better understanding of some of the traffic control systems, the Linux Advanced Routing and Traffic Control manual is a good place to look. Starting at chapter 9, it goes into some detail on how some of the the algorithms available work and how to implement them. http://lartc.org http://lartc.org/howto/lartc.qdisc.html thanks again, Rich -Ryan -- InvisiMax Ryan Langseth Systems Administrator [EMAIL PROTECTED] work: (218) 745-6030 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
And this is the benefit of using Star-Os at the customer end. We cbq them there. It would be great if thee was some advanced bandwidth management features available as well. Rich Comroe wrote: My precious! It further occurs to me that even if you have radio built-in bw management you would also be pretty smart to have bw management enabled at the head-end, too. Why? Radio built-in bw management will block customer excess rate inbound customer traffic from wasting your rf capacity between CPE Access Point, but if you've got rf backhaul to the site you need head-end bw management as well to block excess rate outbound customer traffic from wasting the rf backhaul bw before it ever reaches the AP's outbound bw management. And the outbound bw is typically greater than the inbound bw anyway. So it now looks prudent to me to have BOTH bw management built into the radios, AND at the head-end. Rich - Original Message - From: Jason To: WISPA General List Sent: Thursday, January 25, 2007 2:31 PM Subject: Re: [WISPA] Advanced Bandwidth Management From what I understand, there are many types of qdisc (HTB, CBQ, Prio, on and on) that you can invoke with the 'tc' linux command. HTB is the 'Hierarchical Token Bucket' that you hear a lot about because it works well. HTB should not be confused with 'Hierarchical TOLKIEN Bucket' that has something to do with the Lord of the Rings. 'Leaky Bucket' is a reference to my brains as I try to grasp bandwidth shaping. Jason Rich Comroe wrote: Great reference and I've learned a tremendous amount from this list. I learned that I have been mis-using the term Leaky Bucket. I now understand that what Jason described to the list is Token Bucket (I was totally wet in my earlier reply calling it Leaky Bucket). Radios that implement bw management vary considerably in sophistication of their bw management algorithms. I'm really impressed with the Alvarion bw management. Canopy has bw management built-in as well, but it seems less sophisticated. I'm also impressed with what I've learned Linux advanced bw management can do at the head-end if your radios don't. Given radios can be bridged or not, bw management in the in-radio implementations seem better ... because I don't see how head-end bw management can distinguish between bw to multiple destinations behind the same customer radio if the radios are bridged. Even if the radios are not bridged, then I'd see in-radio bw management as 'still' better because bw limited at the customer radio doesn't chew up inbound rf capacity, while in head-end bw management the rf inbound capacity gets burned whether the traffic is ultimately limited or not. Anyways, I'm getting a great deal from the discussion, and would love to hear if other radios have built-in bw management and what method is use for comparison (any Trango users who could possibly comment?). Rich From: Ryan Langseth To: WISPA General List Sent: Thursday, January 25, 2007 12:44 AM Subject: Re: [WISPA] Advanced Bandwidth Management On Jan 24, 2007, at 8:25 PM, Rich Comroe wrote: Thanks much. I love it when you talk technical! Sorry, couldn't help it... No really, the devil is always in the details in these things. This is just the detail I was looking for. After I digest I hope I may send questions your way off-list. Still hoping operators using other brands will share what bw management algorithms they may have built-in. If you are looking for a better understanding of some of the traffic control systems, the Linux Advanced Routing and Traffic Control manual is a good place to look. Starting at chapter 9, it goes into some detail on how some of the the algorithms available work and how to implement them. http://lartc.org http://lartc.org/howto/lartc.qdisc.html thanks again, Rich -Ryan -- InvisiMax Ryan Langseth Systems Administrator [EMAIL PROTECTED] work: (218) 745-6030 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
They aren't saying 10MB for $10. They are saying DSL for $10 -- most likely DSL Lite. It will probably be felt my the dial-up providers like NetZero, since the price is used to add subs. New subs added is the metric that Wall St. is watching. SBC learned that at $10 they can convert dial-up users to DSL and grab some penny-pinching cable users. (Churn is not mentioned). - Peter Tom DeReggi wrote: But we can;t forget about delivery! Anyone can create a price sheet, but can they deliver? The day the competors delivers 10 meg for $10 per month, and consistently delviers to the majority of the population, it will be past the time to look into being in another business. But I'm betting on the fact that they won't get there as fast as they advertise, at the quality level customers demand.. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Advanced Bandwidth Management
Mikrotik can do this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Sent: Wednesday, January 24, 2007 11:27 AM To: WISPA General List Subject: [WISPA] Advanced Bandwidth Management List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
Good point, but it is my understanding that with a well behaved TCP/IP stack the flow control is handled end to end on TCP traffic, so if it is just the last hop (AP to CPE) that is 'dropping' packets the rate is backed up stream so the sender will not continue to slam your connection, the backoff is across the whole virtual pipe. Now, if you have a poorly behaving TCP/IP stack this will not hold true, but you should only see this on an ancient windows machine and it would only show in the customer trying to upload. Sam Tetherow Sandhills Wireless Rich Comroe wrote: My precious! It further occurs to me that even if you have radio built-in bw management you would also be pretty smart to have bw management enabled at the head-end, too. Why? Radio built-in bw management will block customer excess rate inbound customer traffic from wasting your rf capacity between CPE Access Point, but if you've got rf backhaul to the site you need head-end bw management as well to block excess rate outbound customer traffic from wasting the rf backhaul bw before it ever reaches the AP's outbound bw management. And the outbound bw is typically greater than the inbound bw anyway. So it now looks prudent to me to have BOTH bw management built into the radios, AND at the head-end. Rich - Original Message - From: Jason To: WISPA General List Sent: Thursday, January 25, 2007 2:31 PM Subject: Re: [WISPA] Advanced Bandwidth Management From what I understand, there are many types of qdisc (HTB, CBQ, Prio, on and on) that you can invoke with the 'tc' linux command. HTB is the 'Hierarchical Token Bucket' that you hear a lot about because it works well. HTB should not be confused with 'Hierarchical TOLKIEN Bucket' that has something to do with the Lord of the Rings. 'Leaky Bucket' is a reference to my brains as I try to grasp bandwidth shaping. Jason Rich Comroe wrote: Great reference and I've learned a tremendous amount from this list. I learned that I have been mis-using the term Leaky Bucket. I now understand that what Jason described to the list is Token Bucket (I was totally wet in my earlier reply calling it Leaky Bucket). Radios that implement bw management vary considerably in sophistication of their bw management algorithms. I'm really impressed with the Alvarion bw management. Canopy has bw management built-in as well, but it seems less sophisticated. I'm also impressed with what I've learned Linux advanced bw management can do at the head-end if your radios don't. Given radios can be bridged or not, bw management in the in-radio implementations seem better ... because I don't see how head-end bw management can distinguish between bw to multiple destinations behind the same customer radio if the radios are bridged. Even if the radios are not bridged, then I'd see in-radio bw management as 'still' better because bw limited at the customer radio doesn't chew up inbound rf capacity, while in head-end bw management the rf inbound capacity gets burned whether the traffic is ultimately limited or not. Anyways, I'm getting a great deal from the discussion, and would love to hear if other radios have built-in bw management and what method is use for comparison (any Trango users who could possibly comment?). Rich From: Ryan Langseth To: WISPA General List Sent: Thursday, January 25, 2007 12:44 AM Subject: Re: [WISPA] Advanced Bandwidth Management On Jan 24, 2007, at 8:25 PM, Rich Comroe wrote: Thanks much. I love it when you talk technical! Sorry, couldn't help it... No really, the devil is always in the details in these things. This is just the detail I was looking for. After I digest I hope I may send questions your way off-list. Still hoping operators using other brands will share what bw management algorithms they may have built-in. If you are looking for a better understanding of some of the traffic control systems, the Linux Advanced Routing and Traffic Control manual is a good place to look. Starting at chapter 9, it goes into some detail on how some of the the algorithms available work and how to implement them. http://lartc.org http://lartc.org/howto/lartc.qdisc.html thanks again, Rich -Ryan -- InvisiMax Ryan Langseth Systems Administrator [EMAIL PROTECTED] work: (218) 745-6030 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless
Re: [WISPA] Advanced Bandwidth Management
Here is a link that does a decent job describing the Mikrotik implementation using burst-limit, burst-threshold and max-limit. Scroll down to the section labeled Burst (second to last section). http://www.mikrotik.org.pl/jakto.php?g=13PHPSESSID=5193496d65073e909b1f130b2e234135 Sam Tetherow Sandhills Wireless Dennis Burgess - 2K Wireless wrote: Mikrotik can do this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Sent: Wednesday, January 24, 2007 11:27 AM To: WISPA General List Subject: [WISPA] Advanced Bandwidth Management List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt Jason wrote: List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
I believe what you would be looking for is something like a NetEqualizer. This device works to equalize all your traffic to make sure one user is not using up all the pipe. It works by tracking active connections by IP address, if it finds a user hogging the bandwidth it puts a delay on their connection to slow it down until they are back under control. The best thing about this device is the price they are inexpensive compared to the very high end devices. Mike Pearson Matt Liotta wrote: Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt Jason wrote: List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Advanced Bandwidth Management
grin...read my mind. Brad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Liotta Sent: Wednesday, January 24, 2007 11:49 AM To: WISPA General List Subject: Re: [WISPA] Advanced Bandwidth Management Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt Jason wrote: List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Advanced Bandwidth Management
We haven't used them but they do have an impressive client list, here's the link http://netequalizer.com/indexgoo.php Chuck Profito 209-988-7388 CV-ACCESS, INC [EMAIL PROTECTED] Providing High Speed Broadband to Rural Central California -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Sent: Wednesday, January 24, 2007 9:27 AM To: WISPA General List Subject: [WISPA] Advanced Bandwidth Management List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
I'm with you jason - the subject of bandwidth management is an important one, and the fact is that new applications (crapplications?!) are appearing all the time which are pushing the business model into a tight spot. We have competing forces - on the one hand, we purchase expensive dedicated bandwidth, and on the other, we sell low cost shared bandwidth. We cannot sell for $34.95 what we pay $300 for. But yet we get customers who come to us and ask us to do exactly that. The days of the unmanaged bandwidth network are numbered, if they are not already at an end. There's certainly some solutions available for head-end bandwidth management - like the bandwidth arbitrator which was already mentioned - but the most effective management starts with subscriber side and _not allowing_ traffic flows that exceed that subscribers limits, into the network in the first place. The Arbitrator can only deal with it once it reaches your noc (or wherever else you've placed it), but this doesn't do anything for portscanning viruses or other traffic which would get dropped - but also would have also consumed your precious network resouces first before getting to that choke point. I'd really like to see an isp industry standardization effort on the subject of bandwidth subscription policies, something that we can present to customers as the uniform definition of what we provide in terms of bandwidth and allocation and priority and so forth that could then be used as a 'sticker' when shopping around for services Mike (the rambler) Jason wrote: List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
On Wed, 24 Jan 2007, Matt Liotta wrote: Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? When your head dips below the cloud cover, you will realize that not everyone has this luxury. Many on this list are selling residential service at lowball rates. Also, most of them are paying premium prices for bandwidth. You can't build a business model around unlimited access for $30/month and pay for an $800+ T1, if you allow every even 128k without restrictions. -- Butch Evans Network Engineering and Security Consulting 573-276-2879 http://www.butchevans.com/ My calendar: http://tinyurl.com/y24ad6 Training Partners: http://tinyurl.com/smfkf Mikrotik Certified Consultant http://www.mikrotik.com/consultants.html -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
This thread should not hit a nerve, as I think it has. I've read a lot of your stuff, so I know you're a bright guy. You know that while telephone talk-time may not be metered for many phone services that if everyone picked up their phone that the chances of getting a trunk out of your local office would drop to zero. That's just science, not marketing. No matter how your terms of service are sold there's a real engineering metric called erlangs per user, and it's expected value is much-much less than 1. This is traffic engineering, not marketing. It's the real science behind what most wisps describe as oversubscription. The lower the average erlangs per user the more users a given bandwidth serves. There are actually textbooks and mature classes on the subject going back 40 years (the science was matured long ago by telephone engineering from the Bell System). It's a legitimate concern what to do about users that statistically use x10 fold, x100 fold, or even x1000 fold or more over the average. Unless you're a service provider with a statistically HUGE number of users you cannot afford to let the averages take care of themselves as phone carriers do. Even so, with the typically small number of users per access point, a statistically anomalous user can destroy service to other customers unlucky to share the same channel ... it's something that simply MUST be addressed. What the writer described, I call the leaky bucket algorithm, and there are some wisp manufacturers that actually code this into their radio products (no need to perform it via a head-end traffic shaper). If your deployed radios do not, a head-end traffic shaper can do the same thing. It's referred to as the leaky bucket algorithm because it's has a physical similarity. Imagine a bucket of a given size that has a leak ... through which the user draws water. In an instant, the user cannot draw more water than the bucket currently holds (referred to as burst size). Once the bucket, or burst size, has been drawn, the user cannot draw more than the bucket's refill rate (referred to as sustained rate). Radios with this built-in typically specify a burst size and sustained rate per CPE, for inbound, and for outbound (4 parameters in total). I'm familiar with many wisps that set the burst sizes to 10M (don't know any that set it to 1G as the author hypothesized), and set sustained rates at 256kbps or 384kbps. The interesting thing about the algorithm is that burst size is dimensionless (it's only a size, and not a rate ... the rate is determined by the radio channel and traffic levels), while the sustained rate is a true rate (bits/sec). I appologize for the lecture, but traffic engineering has always been a topic of interest to me going way back. But I have great concerns for the viability of wisps that don't appreciate the issue (unless they only sell business service where throughput per user is sold with SLAs ... engineering to a high erlang per user, or equivalently described as a low oversubscription rate). regards, Rich - Original Message - From: Matt Liotta To: WISPA General List Sent: Wednesday, January 24, 2007 11:49 AM Subject: Re: [WISPA] Advanced Bandwidth Management Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt Jason wrote: List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List
RE: [WISPA] Advanced Bandwidth Management
Matt, What an asinine comment! You sound like you ought to be giving bandwidth away with the pride and carefree attitude that you portrayed with such indignant comment. If the truth was known you aren't any different than anyone else on this list - - the sub gets what they pay for. You can talk trash all you want, but the truth is you need to dig your head out of your ass and quit acting like - - well - - - - enough said. Mac Dearman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Liotta Sent: Wednesday, January 24, 2007 11:49 AM To: WISPA General List Subject: Re: [WISPA] Advanced Bandwidth Management Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt Jason wrote: List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Advanced Bandwidth Management
in the buffers system. As certain applications are very sensitive to delay, if relatively high delays are permitted, these applications may suffer from poor performance due to data accumulation in the buffers from other applications, such as FTP. The Maximum Delay parameter limits the number of available buffers. Data that is delayed more than the permitted maximum delay is discarded. If the SU supports applications that are very sensitive to delay, the value of the Maximum Delay should be decreased. Valid values range from 300 to 1 milliseconds. The default value is 5000 (milliseconds). 4.2.6.6.2.7 Graceful Degradation Limit (AU only) Sets the limit on using the graceful degradation algorithm. In cases of over demand, the performance of all SUs is degraded proportionally to their CIR (IR=(100%-k%) x CIR). The graceful degradation algorithm is used as long as k ≤ K, where K is the Graceful Degradation Limit. Beyond this point the simple brute force algorithm is used. The Graceful Degradation Limit should be raised in proportion to the demand in the cell. The higher the expected demand in a cell, the higher the value of the Graceful Degradation Limit. Higher demand can be expected in cases of significant over subscription and/or in deployments where a high number of subscribers are in locations without proper communication with the AU at the highest data rate. The available values range from 0 to 70 (%). The default value is 70 (%). 4.2.6.6.2.8 MIR Only Option (AU only) When the MIR Only Option is enabled, it forces the MIR/CIR algorithm to use MIR values only. The MIR/CIR algorithm determines the actual information rate for each of the supported SUs under changing conditions of demand, based on the configured CIR and MIR values. When the MIR Only Option is enabled, the MIR/CIR algorithm is overridden and forced to operate with MIR values only. For example, the AU attempts to enable all SUs to transmit/receive information at the specified MIR value. When enabled, the graceful degradation algorithm, which is a part of the CIR/MIR algorithm, is also disabled. The default is Enable. 4.2.6.6.2.9 Show MIR/CIR Parameters Displays the current values of the MIR and Patrick Leary AVP WISP Markets Alvarion, Inc. o: 650.314.2628 c: 760.580.0080 Vonage: 650.641.1243 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Comroe Sent: Wednesday, January 24, 2007 4:01 PM To: WISPA General List Subject: Re: [WISPA] Advanced Bandwidth Management Fascinating. I only spoke of leaky bucket because that's practically a match to what Jason originally described to the list (and I happen to know of radios that have this algorithm internally programmed -- happens to be Canopy). But I presume there are other algorithms programmed to different manufacturer's radios. Patrick, is it possible to share details of the Alvarion implemented 4th gen algorithm you spoke of? This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Advanced Bandwidth Management
Matt (Liota) and the rest of us need to remember that Matt sells only dedicated ptp links. He does not deploy a PMP, so his inputs and answers generally do not reflect a pmp environment or its many orders higher complexity. That's not a dig Matt, it is just reality. Ptp is a far different world and much easier. Patrick Leary AVP WISP Markets Alvarion, Inc. o: 650.314.2628 c: 760.580.0080 Vonage: 650.641.1243 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mac Dearman Sent: Wednesday, January 24, 2007 4:23 PM To: 'WISPA General List' Subject: RE: [WISPA] Advanced Bandwidth Management Matt, What an asinine comment! You sound like you ought to be giving bandwidth away with the pride and carefree attitude that you portrayed with such indignant comment. If the truth was known you aren't any different than anyone else on this list - - the sub gets what they pay for. You can talk trash all you want, but the truth is you need to dig your head out of your ass and quit acting like - - well - - - - enough said. Mac Dearman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Liotta Sent: Wednesday, January 24, 2007 11:49 AM To: WISPA General List Subject: Re: [WISPA] Advanced Bandwidth Management Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt Jason wrote: List, Several times in the last few weeks the topic of bandwidth management has been discussed, but I Still Haven't Found What I'm Lookin' For... Here's what I'd like to do: 1. Each user starts with a big Internet Pipe. This way casual surfing and emails, etc. happen nice and snappy. 2. If a user downloads a big chunk of data, he needs to be shaped to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). 3. Step 2 repeats over and over several times if the user continues to download. 4. After the user quits hogging the network, his bandwidth is restored in stages (backwards of 2 and 3). I know this, or at least similar things to it, are being done out there. The HughesNet satellite FAP works something like this (I don't know the actual values): 1. Each user has a Bit Bucket that holds 1 Gig of bandwidth. 2. The Bit Bucket is replenished at 128k. 3. The speed at which the user can download from his bit bucket is 1meg. 4. If the user uses all the bits in his bucket faster than they are replenished, he eventually gets only 128k. Does anyone know how to get something like this going? I am especially interested in Linux/Ubuntu solutions. Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses(190). This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses(42). This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Advanced Bandwidth Management
My hat is off to you John! You possess skills that I don't in saying things that I should have said in a different fashion :-) I am not now - nor have I ever been in a class that is politically correct and unless something serious happens - - - - - never will be :-) Mac -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Vogel Sent: Wednesday, January 24, 2007 3:12 PM To: WISPA General List Subject: Re: [WISPA] Advanced Bandwidth Management I would suspect that the customer (as is the case in much of the world, not necessarily in the limited world you may operate in) does not want to, or in many case could not pay for such a pipe. In many areas of the US, especially rural, bandwidth is extremely expensive. Customers do not want to pay close to $1k / month for their residential connection to the internet, yet the customer would like to access the internet at speed approaching 1.5 mbps (or even faster) whenever they can. In such a case it makes sense, is good business practice, and not at all unethical to sell customers shared bandwidth. In cases such as these, the question posed by the OP is a valid question, and deserves an answer other than one which implies that they may be doing something they should not be. The world is a big place. It is good to get out and see parts of it you may not have seen lately. John Matt Liotta wrote: Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
Butch, That's not correct. About 5 years ago, we were paying $1,500 per T1 and selling T1 speed wireless for $250 per month. Seven to eight years ago we were paying $3,000 per T1 and selling wireless T1 for $250 per month. This is the entire ISP business model. Travis Microserv Butch Evans wrote: On Wed, 24 Jan 2007, Matt Liotta wrote: Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? When your head dips below the cloud cover, you will realize that not everyone has this luxury. Many on this list are selling residential service at lowball rates. Also, most of them are paying premium prices for bandwidth. You can't build a business model around unlimited access for $30/month and pay for an $800+ T1, if you allow every even 128k without restrictions. -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
OR, we could stop playing the Cable Co. and Telco games with their up to 3meg and up to 7meg connections for $34.95 and just start selling what they get. We started selling 512k, 1meg, 1.5meg and 2meg connections (up and down, guaranteed speed 24x7) about 3 years ago. It was the best thing we ever did... people get what they pay for, and when they need more, they buy more. No games, no burstable speeds, etc. Make your customers pay for what they need and use. Travis Microserv Blair Davis wrote: We sell mainly to residential users and to some small businesses. We are quite rural, and my cost for a T-1 is $450 per month. My pending fiber hookup is $1100 per month for 5Mbit. A bit ago, a business customer's new IT consultant complained that the 256Kbit committed rate for $60 a month was over priced. He demanded a 1Mbit committed rate and no price change. I explained this was not possible. He was quite nasty and told me he was recommending that the customer find a new ISP. I, fed up with his big city attitude, told him to go right ahead. He said to come pick up the gear on this Friday. Although, I might have lost my temper a bit and used some words that the FCC doesn't permit on the phone.. After he was quoted $600 per month for a T1, (and $9500 install), and a 3 month lead time, he called me back... He decided that my offer of 1Mbit committed rate (6am-6pm, Mon-Fri) and a 256Kbit committed rate at other times) for $250 a month was a damn good deal.. The point of this, is that, for many customers, pricing and bandwidth expectations are being driven by the cheap bandwidth in the large cites Out here in the real world, it don't work that way. The other point is, that with a good mix of residential and business customers, and a little creative thinking, one can match their usage patterns to minimize ones peak bandwidth requirements while still providing the 'fast, snappy feel' that the users prefer Just my $.02 J. Vogel wrote: I would suspect that the customer (as is the case in much of the world, not necessarily in the limited world you may operate in) does not want to, or in many case could not pay for such a pipe. In many areas of the US, especially rural, bandwidth is extremely expensive. Customers do not want to pay close to $1k / month for their residential connection to the internet, yet the customer would like to access the internet at speed approaching 1.5 mbps (or even faster) whenever they can. In such a case it makes sense, is good business practice, and not at all unethical to sell customers shared bandwidth. In cases such as these, the question posed by the OP is a valid question, and deserves an answer other than one which implies that they may be doing something they should not be. The world is a big place. It is good to get out and see parts of it you may not have seen lately. John Matt Liotta wrote: Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
On Wed, 24 Jan 2007, Travis Johnson wrote: That's not correct. About 5 years ago, we were paying $1,500 per T1 and selling T1 speed wireless for $250 per month. Seven to eight years ago we were paying $3,000 per T1 and selling wireless T1 for $250 per month. This is the entire ISP business model. And you allow a single customer to pay you $250/month for what you pay $1500/month? And you make money how? What I read in Matt's post (below) is that if they pay for the 1.5Mbit, they should get it...anytime, all the time. As in dedicated. Perhaps I mistook his intention, but from reading others responses, I'd guess I didn't. FWIW, I have been in this business long enough to understand how it works. I am not saying that you can't purchase a T1 and sell a T1 speed to more than one person and get away with it. But keep in mind, that selling internet access to businesses 7-8 years ago is not even the same as it is today. Back then, businesses did not use NEAR the average bandwidth they use today. Even so, they use much less average BW than do residential subs (in most cases). SO, if your cost/meg goes down, your utilization is going up. Your bottom line will show you that what I am saying is true (and I know you understand this anyway). On Wed, 24 Jan 2007, Matt Liotta wrote: Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -- Butch Evans Network Engineering and Security Consulting 573-276-2879 http://www.butchevans.com/ My calendar: http://tinyurl.com/y24ad6 Training Partners: http://tinyurl.com/smfkf Mikrotik Certified Consultant http://www.mikrotik.com/consultants.html -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
Thanks much. I love it when you talk technical! Sorry, couldn't help it... No really, the devil is always in the details in these things. This is just the detail I was looking for. After I digest I hope I may send questions your way off-list. Still hoping operators using other brands will share what bw management algorithms they may have built-in. thanks again, Rich - Original Message - From: Patrick Leary To: WISPA General List Sent: Wednesday, January 24, 2007 6:23 PM Subject: RE: [WISPA] Advanced Bandwidth Management Rich, --- Here is the detail from the manual. I have first cut pasted the graceful degradation math detail: Graceful Degradation Limit (AU only) Sets the limit on using the graceful degradation algorithm. In cases of over demand, the performance of all SUs is degraded proportionally to their CIR (IR=(100%-k%) x CIR). The graceful degradation algorithm is used as long as k ≤ K, where K is the Graceful Degradation Limit. Beyond this point the simple brute force algorithm is used. The Graceful Degradation Limit should be raised in proportion to the demand in the cell. The higher the expected demand in a cell, the higher the value of the Graceful Degradation Limit. Higher demand can be expected in cases of significant over subscription and/or in deployments where a high number of subscribers are in locations without proper communication with the AU at the highest data rate. The available values range from 0 to 70 (%). --- And here is the whole bit about how the mechanism works 4.2.6.6.2 MIR and CIR Parameters The CIR (Committed Information Rate) specifies the minimum data rate guaranteed to the relevant subscriber. The MIR (Maximum Information Rate) value specifies the maximum data rate available for burst transmissions, provided such bandwidth is available. Under normal conditions, the actual Information Rate (IR) is between the applicable CIR and MIR values, based on the following formula: IR=CIR+K(MIR - CIR). In this formula K is between 0 and 1 and is determined dynamically by the AU according to overall demand in the cell and the prevailing conditions that influence the performance of the wireless link. In some situations the minimum rate (CIR) cannot be provided. This may result from high demand and poor wireless link conditions and/or high demand in over-subscribed cells. When this occurs, the actual information rate is lower than the CIR. The simple solution for managing the information rate in such cases can result in an unfair allocation of resources, as subscribers with a higher CIR actually receive an IR lower than the CIR designated for subscribers in a lower CIR bracket. A special algorithm for graceful degradation is incorporated into the AU, ensuring that the degradation of performance for each individual Subscriber Unit is proportional to its CIR. The MIR/CIR algorithm uses buffers to control the flow of data. To balance the performance over time, a special Burst Duration algorithm is employed to enable higher transmission rates after a period of inactivity. If no data is received from the Ethernet port during the last N seconds, the unit is allowed to transmit N times its CIR value without any delay. For example, after a period of inactivity of 0.5 seconds, a unit with CIR = 128 Kbps can transmit up to 128 Kbits x 0.5 = 64 Kbits without any delay. 4.2.6.6.2.1 MIR: Downlink (SU only) Sets the Maximum Information Rate of the downlink from the AU to the SU. The MIR value cannot be lower than the corresponding CIR value. Available values range and default value are shown inTable 4-12. The actual value will be the entered value rounded to the nearest multiple of 128 (N*128). 4.2.6.6.2.2 MIR: Uplink (SU only) Sets the Maximum Information Rate of the up-link from the SU to the AU. The MIR value cannot be lower than the corresponding CIR value. Available values range and default value are shown in Table 4-12. The actual value will be the entered value rounded to the nearest multiple of 128 (N*128). 4.2.6.6.2.3 CIR: Downlink (SU only) Sets the Committed Information Rate of the downlink from the AU to the SU. The CIR value cannot be higher than the corresponding MIR value. Available values range and default value are shown inTable 4-13. The actual value will be the entered value rounded to the nearest multiple of 128 (N*128). 4.2.6.6.2.4 CIR: Uplink (SU only) Sets the Committed Information Rate of the uplink from the SU to the AU. The CIR value cannot be higher than the corresponding MIR value. Available values range and default value are shown in Table 4-13. The actual value will be the entered value rounded to the nearest multiple of 128 (N*128). Table 4-12: MIR Ranges and Defaults MIR Uplink MIR Downlink Unit Type Range (Kbps) Default (Kbps) Range (Kbps) Default (Kbps) SU-3 128-2,048 2,048 128-3,072 3,072 SU-6 128-4,096 4,096
Re: [WISPA] Advanced Bandwidth Management
That is exactly the issue I have. The system I need this for is an extremely rural retirement community, satellite-connected WISP with 1meg down 128k up and 266megs total per day limit (8gig spread over 30 days). Just one all night P2P session will cause the upstream provider to cut the connection to 56k up/down for weeks until the total usage drops to 6gig in the previous 30 days. Then nobody's happy. Meanwhile, babyboomers are retiring and moving from the city where they got 4 to 6 meg Roadrunner and Cox connections and expect the same service at the same pricepoint. T1's run up to 2200$/month. Needless to say, I am also looking for other bandwidth sources... Even with a GOOD Internet pipe, I'll need software to make sure everyone plays fair, especially at the dawn of IPTV. Jason On Wed, 24 Jan 2007, Matt Liotta wrote: Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? When your head dips below the cloud cover, you will realize that not everyone has this luxury. Many on this list are selling residential service at lowball rates. Also, most of them are paying premium prices for bandwidth. You can't build a business model around unlimited access for $30/month and pay for an $800+ T1, if you allow every even 128k without restrictions. -- Butch Evans Network Engineering and Security Consulting 573-276-2879 http://www.butchevans.com/ My calendar: http://tinyurl.com/y24ad6 Training Partners: http://tinyurl.com/smfkf Mikrotik Certified Consultant http://www.mikrotik.com/consultants.html -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Advanced Bandwidth Management
On Jan 24, 2007, at 8:25 PM, Rich Comroe wrote: Thanks much. I love it when you talk technical! Sorry, couldn't help it... No really, the devil is always in the details in these things. This is just the detail I was looking for. After I digest I hope I may send questions your way off-list. Still hoping operators using other brands will share what bw management algorithms they may have built-in. If you are looking for a better understanding of some of the traffic control systems, the Linux Advanced Routing and Traffic Control manual is a good place to look. Starting at chapter 9, it goes into some detail on how some of the the algorithms available work and how to implement them. http://lartc.org http://lartc.org/howto/lartc.qdisc.html thanks again, Rich -Ryan -- InvisiMax Ryan Langseth Systems Administrator [EMAIL PROTECTED] work: (218) 745-6030 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
