Bursting Is for the Birds (Burstable Internet Speed)


Internet Bursting

By Art Reisman, CTO, http://www.netequalizer.com

Art Reisman CTO www.netequalizer.com

Art Reisman

We posted this article back in May 2008. It was written from the perspective of an ISP; however many consumers are finding our site and may find after reading this article that their burstable Internet service is not all its cracked up to be.  If you are a home internet user, and a bit of a geek,  you might find this article on burstable Internet Speeds thought provoking.

The Demand Side

From many of our NetEqualizer users, we often hear, “I want to offer my customers a fixed-rate one-megabit link, but at night, or when the bandwidth is there, I want to let them have more”. In most cases, the reasons for doing this type of feature are noble and honest. The operator requesting it is simply trying to allow his or her customers access to a resource that has already been paid for. Call it a gesture of good faith. But, in the end, it can lead to further complications.

The problem with this offering is that it can be like slipping up while training your dog. You have to be consistent if you don’t want problems. For example, you can’t let the dog lick scraps off the table on Sunday and then tell him he can’t do it on Monday. Well, the same is true for your customers (We’re not insinuating they are dogs, of course). If you provide them with higher speeds when your network isn’t busy, they may be calling you when your contention ratios are at their peak during times of greater usage. To avoid this, it is best to not to let them ever go above their contracted amount – even when the bandwidth is available.

The Supply Side

Now that we’ve covered the possible confusion bursting may cause for your end-customer, we should take a look at how bursting affects an ISP from the perspective of variable rate bandwidth being offered by your upstream provider.

Back in 2001, when the NetEqualizer was just a lone neuron in the far corner of my developing brain, a partner and I were running a fledgling local neighborhood WISP. To get started, we pulled in a half T1 from a local bandwidth provider.

The pricing is where things got complicated. While we had a half T1, if we went over that more than five percent of the time, the provider was going to charge us large random amounts of cash. Sort of like using too many minutes on your cell phone.

According to our provider, this bursting feature was touted as a great benefit to us as the extra bandwidth would be there when we needed it. On the other hand, there was also this inner-fear of dipping into the extra bandwidth as we knew things could quickly get out of our control. For example, what if some psycho customer drove my usage over the half T1 for a month and bankrupted me before we even detected it? This was just one of the nightmare scenarios that went through my head.

Just to give you a better idea of what the experience was like, think of it this way. Have you ever made an international call from a hotel because it was your only choice and then gotten nailed with a $20 fee for a two minute conversation? This experience was kind of like that. You don’t really know what to expect, but you’re pretty sure it’s not going to be good.

I’m a business owner whose gut instinct is to live within my means. This includes determining how much bandwidth my business needs by sizing it correctly and avoiding hidden costs.

Yet, for many business owners this process is made more complicated by the policies of their bandwidth providers, bursting being a major factor. Well, it’s time to fight back. If you have a provider that offers you bursting, ask them the following questions:

  • Can I have in writing how this bursting feature works exactly?
  • Is a burst one second, 10 seconds, or 10 hours at a time?
  • Is it available all of the time, or just when my upstream provider(s) circuits are not busy?
  • If it is available for 10 hours, can I just negotiate a flat rate for this extra bandwidth?
  • Can you just turn it off for me?

For many customers that we’ve spoken with, bursting is creating more of a fear of overcharge than any tangible benefits. On the other hand, the bursting feature is often helping their upstream provider.

For an upstream provider who is subdividing a large Internet pipe into smaller pipes for resale, it is difficult to enforce a fixed bandwidth limit. So, rather than purchase expensive equipment to divvy up their bandwidth evenly amongst their customers, providers may instead offer bursting as a “feature”. And, while they are at it, they’ll charge you for something that you likely don’t really need.

So, think twice about who’s really benefiting from bursting and know that a few questions can go along way in evening out the deal with your provider. Chances are bursting may be doing your company more harm than good.

In short, while bursting may seem harmless on the surface for both the ISP and the customer, over time the potential problems can significantly outweigh the benefits. Put simply, the best way to avoid this is to maintain consistency at all times and leave bursting for the birds.

The birth of a new kind of new kind of Packet Shaper (NetEqualizer)

Today my attention was drawn to a forum thread about setting up queuing and bandwidth fairness on a Cisco Router. The techs in the discussion were obviously very familiar with Cisco and its internal programming language. Needless to say it was a very low level discussion and  to make any sense of it would require  sort a Cisco certification on the inner workings of their IOS programming language. The discussion reminded me of a conversation I had back in 2002 when the idea of turn key bandwidth controller popped into my head

In 2002  I was running a start up WISP with a partner. One issue that we saw coming was sharing bandwidth on a tightly contested T1. We decided it was worth looking into what was available, was there something we could just plug in to handle this and get on with our core business of  running the WISP.
My day job at the time was at Bell Labs, and just recently there had been quite  a few defections to Cisco.  So I  decided to tap some of more former coworkers to see if Cisco had anything turn key picked up the phone and asked a couple of peers what a Cisco box could do  support of some form of turn key fairness. ‘Well you can program the IOS bios queues bla bla” I had heard enough. It seemed that although it was definitely possible to do this with Cisco, I just wanted  something to plug  in and forget about it.  I did not have money to hire a Cisco tech and figured many other start up WISPS in my position were in the same boat. Little did I realize at the time, that the NetEqualizer would become an International hit, distributed across all industries (Hospitals, Cable Companies, Universities etc) around the world over the next 6 years.

The model  of how to approach this issue of fairness was already widely used  in the computer server world. Most people are not concerned with  fairness of processes or threads on web server or data base server? Why is that ? Most  modern computer servers  have some form of operating system that insures that the processes running don’t dominate the central processor (usually Linux). The basic idea is that a little timer that keeps track of a processors resources and how much a process has used if they HOG too much this timer kicks and allows others to get their turn.

The point of this story is there is no manual intervention needed, computers are so cheap that it would be absurd to pay somebody to do this, but that was not always the case. As late as 1986 the Main Frame computer dominated data processing, and with a main frame came a computer operator , a human who had the task of making sure jobs (as there were called) ran to completion in a timely manner,  as well as making sure tape drives were loaded etc.

Do you see the parallel here ? As computers became cheaper it was not economical to employ somebody to watch over this resource, the job still existed  but it was automated and incorporated into the operating system.

Flash forward to 2002, what my Cisco  freinds were  proposing was a labor intensive solution to managing a resource (bandwidth). So the idea was to take this one aspect of managing a network and essentially fire the operator (or the Cisco programmer) And so it was born an automated fairness device for sharing bandwidth and we have no looked back since.

Resources on computers and ways to handle this type of thing were invented back in the 70’s and became wide spread with the death of the card reader.

Editors note: CIsco is a fine product and perhaps there is some easy way to perform this function and I am just too stupid to understand.

%d bloggers like this: