|
||||||||||
|
||||||||||
|
||||||||||
|
||||||||||
Editor’s Note: The folks over at ISP Finder (a nice service for those of you looking for ISP options) posted the following article this week that we thought was interesting.
Today there are thousands of ISP’s (Internet Service Providers), but it all started with a handful of dial-up services. Some of the names you will recognize and some of them you will not. All of them played a part in the early beginnings of what is now known as the world wide web.
1) Compuserve: Compuserve is one of the oldest and yet, still well-known online service providers. So what became of Compuserve? In 1980, Compuserve was purchased by H&R Block (that’s correct, the tax preparers). Approximately 20 years later they decided to sell off Compuserve. AOL offered a stock trade which wasn’t accepted but eventually it did end up under their umbrella via being purchased by Worldcom instead. The remaining aspects of Compuserve are now clothed within the Verizon Network.
2) Mindspring: This early ISP was located in Georgia. In the year 2000 Mindspring merged with Earthlink and has remained underneath their wing ever since. In 2008 Earthlink launched its VoIP under the Mindspring name.
Editor’s Note: Due to the many variables involved with tuning and supporting Squid Caching Integration, this feature will require an additional upfront support charge. It will also require at minimum a NE3000 platform. Contact sales@netequalizer.com for specific details.
In our upcoming 5.0 release, the main enhancement will be the ability to implement YouTube caching from a NetEqualizer. Since a squid-caching server can potentially be implemented separately by your IT department, the question does come up about what the difference is between using the embedded NetEqualizer integration and running the caching server stand-alone on a network.
Here are a few of the key reasons why using the NetEqualizer caching integration provides for the most efficient and effective set up:
1. Communication – For proper performance, it’s important that the NetEqualizer know when a file is coming from cache and when it’s coming from the Internet. It would be counterproductive to have data from cache shaped in any way. To accomplish this, we wrote a new utility, aptly named “cache helper,” to advise the NetEqualizer of current connections originating from cache. This allows the NetEqualizer to permit cached traffic to pass without being shaped.
2. Creative Routing – It’s also important that the NetEqualizer be able to see the public IP addresses of traffic originating on the Internet. However, using a stand-alone caching server prevents this. For example, if you plug a caching server into your network in front of a NetEqualizer (between the NetEqualizer and your users), all port 80 traffic would appear to come from the proxy server’s IP address. Cached or not, it would appear this way in a default setup. The NetEqualizer shaping rules would not be of much use in this mode as they would think all of the Internet traffic was originating from a single server. Without going into details, we have developed a set of special routing rules to overcome this limitation in our implementation.
3. Advanced Testing and Validation – Squid proxy servers by themselves are very finicky. Time and time again, we hear about implementations where a customer installed a proxy server only to have it cause more problems than it solved, ultimately slowing down the network. To ensure a simple yet tight implementation, we ran a series of scenarios under different conditions. This required us to develop a whole new methodology for testing network loads through the Netequalizer. Our current class of load generators is very good at creating a heavy load and controlling it precisely, but in order to validate a caching system, we needed a different approach. We needed a load simulator that could simulate the variations of live internet traffic. For example, to ensure a stable caching system, you must take the following into consideration:
To answer this challenge, and provide the most effective caching feature, we’ve spent the past few months developing a custom load generator. Our simulation lab has a full one-gigabit connection to the Internet. It also has a set of servers that can simulate thousands of simultaneous users surfing the Internet at the same time. We can also queue up a set of YouTube users vying for live video from the cache and Internet. Lastly, we put a traditional point-to-point FTP and UDP load across the NetEqualizer using our traditional load generator.
Once our custom load generator was in place, we were able to run various scenarios that our technology might encounter in a live network setting. Our testing exposed some common, and not so common, issues with YouTube caching and we were able to correct them. This kind of analysis is not possible on a live commercial network, as experimenting and tuning requires deliberate outages. We also now have the ability to re-create a customer problem and develop actual Squid source code patches should the need arise.
For many Internet users, one of the first troubleshooting steps when online access seems to slow is to run a simple speed test. And, under the right circumstances, speed tests can be an effective way to pinpoint the problem.
However, slowing Internet speeds aren’t just an issue for the casual user. Over our years of troubleshooting thousands of corporate and other commercial links, a recurring issue has been customers not getting their full-advertised bandwidth from their upstream provider. Some customers are aware something is amiss from examining bandwidth reports on their routers and some of these problems we stumble upon while troubleshooting network congestion issues.
But, what if you have a shared, busy corporate Internet connection such as this — with hundreds or thousands of users on the link at one time? Should a traditional speed test be the first place to turn? In this situation, the answer is “no.” Running a speed test under these conditions is neither meaningful nor useful.
Let me explain.
The problem starts with the overall design and process of the speed test itself. Speed tests usually run short duration files. For example, a 10-megabit file sent over a hundred-megabit link might complete in 0.1 seconds, reporting the link speed to the operator at 100 megabits. However, statistically this is just a snapshot of one very small moment in time and is of little value when the demands on a network are constantly changing. Furthermore, with this type of test, the link must be free of active users, which is nearly impossible when you have an entire office, for example, accessing the network at once.
On these larger shared links, the true speed can only be measured during peak times with users accessing a wide variety of applications persistently over a significant period. But, there is no easily controlled Web speed test site that can measure this type of performance on your link.
Yes, a sophisticated IT administrator can run reports and see trends and make assumptions. And many do. Yet, for some businesses, this isn’t practical.
For this reason, we’ve introduced the NetEqualizer Speed Test Utility.
How Does the NetEqualizer Speed Test Utility Work?
The NetEqualizer Speed Test Utility is an intelligent tool embedded in your NetEqualizer that can be activated from your GUI. On high-traffic networks, there is always a busy hour background load on the link – a baseline if you will. When you set up the speed test tool, you simply tell the NetEqualizer some basics about your network, including:
After turning the tool on, it will keep track of your network’s bandwidth usage. If your usage drops below expected levels, it will present a mild warning on the GUI screen that your bandwidth may be compromised and give an explanation of the deviation. The operator can also be notified by e-mail.
This set up allows bandwidth to be monitored without having to depend on unreliable speed tests or run time-consuming reports, allowing the problem to be more quickly identified and addressed.
For more information about the NetEqualizer Speed Test Utility, contact APconnections at sales@apconnections.net.
APconnections will be releasing ( version 4.7) a bursting feature on their NetEqualizer bandwidth controller this week. What follows is an explanation of the feature and also some facts and information about Internet Bursting that consumers will also find useful.
First an explanation on how the NetEqualizer bursting feature works.
– The NetEqualizer currently comes with a feature that lets you set a rate limit by IP address.
– Prior to the bursting feature, the top speed allowed for each user was fixed at a set rate limit.
– Now with bursting a user can be allowed a burst of bandwidth for 10 seconds with speeds multiples of two , three or four, or any multiple of their base rate limit.
So if for example a user has a base rate limit of 2 megabits a second, and a burst factor of 4, then their connection will be allowed to burst all the way up to 8 megabits for 10 seconds, at which time it will revert back to the original 2 megabits per second. This type of burst will be noticed when loading large Web pages loaded with graphics. They will essentially fly up in the browser at warp speed.
In order to make bursting a “special” feature it obviously can’t be on all the time. For this reason the NetEqualizer by default, will force a user to wait 80 seconds before they can burst again.
Will bursting show up in speed tests?
With the default settings of 10 second bursts and an 80 second time out before the next burst it is unlikely a user will be able to see their full burst speed accurately with a speed test site.
How do you set a bursting feature for an IP address ?
From the GUI
Select
Add Rules->set hard limit
The last field in the command specifies the burst factor. Set this field to the multiple of the default speed you wish to burst up to.
Note: Once bursting has been set-up, bursting on an IP address will start when that IP exceeds its rate limit (across all connections for that IP). The burst applies to all connections across the IP address.
How do you turn the burst feature off for an IP address.
You must remove the Hard Limit on the IP address and then recreate the Hard Limit by IP without bursting defined.
From the Web GUI Main Menu, Click on ->Remove/Deactivate Rules
Select the appropriate Hard Limit from the drop-down box. Click on ->Remove Rule
To re-add the rule without bursting, from the Web GUI Main Menu, Click on ->Add Rules->Hard Limit by IP and leave the last field set to 1.
Can you change the global bursting defaults for duration of burst and time between bursts ?
Yes, from the GUI screen you can select
misc->run command
In the space provided you would run the following command
/usr/sbin/brctl setburstparams my 40 30
The first parameter is the time,in seconds, an IP must wait before it can burst again. If an IP has done a burst cycle it will be forced to wait this long in seconds before it can burst again.
The second parameter is the time, in seconds, an IP will be allowed to burst before begin relegated back to its default rate cap.
The global burst parameters are not persistent, meaning you will need to put a command in the start up file if you want them to stick between reboots.
/usr/sbin/brctl
If speed tests are not a good way to measure a burst, then what do you recommend?
The easiest way would be to extend the burst time to minutes (instead of the default 10 seconds ) and then run the speed test.
With the default set at 10 seconds the best was to see a burst in action is to take a continuous snap shot of an IP’s consumption during an extended download.
One of the things that we have noticed with reporting tools lately, including ntop (the reporting tool we integrate), is that there is no easy way to show instant bandwidth for a user. Most reporting tools smooth out usage over some time period, a 5 minute average is the norm.
For example, this popular Netflow Analyzer touts a 10 minute average, right from the FAQ on their main page it states:
“Real-time Bandwidth Reports for each WAN link
As soon as Netflow data is received, graphs are generated showing details on incoming and outgoing traffic on the link for the last 10 minutes.”
No where can we find a reasonable bandwitdh monitoring tool that will show you instant, as of this second, bandwidth utilization. We are sure somebody will e-mail us to dispute this claim, and if so, we will gladly publish their link and give them credit on our BLOG.
When is an Instant Bandwidth Reporting Tool useful?
1) The five minute average reporting tool is of little use when a customer calls and tells you they are not getting their expected bandwidth on a speed test or video. In these cases it is best to see the instant report while they are consuming the bandwidth, not averaged into a 10 minute aggregate.
2) If a customer has a fixed rate cap, and calls and reports that their VOIP is not working well. The easiest and quickest way is to check what their consumption is during a VOIP call is to see it now. You don’t need a fancy protocol analyzer to tell them they are sucking up their full 1 megabit allocation with their YouTube video specifically. You just need to know that their line is clear and that they are consuming the full megabit at this instant, thus exonerating you (the ISP or support person) from getting drawn down in the dregs of culpability.
Here are some links to other reporting tools.
http://www.javvin.com/packet.html
Here is a snapshot of our screen that allows you take an Instant Bandwidth Snapshot, showing the last second of utilization for a individual IP, Pool, or VLAN on your network.