NetEqualizer News: December 2011

December 21, 2011 — netequalizer

December 2011

Greetings!

Enjoy another issue of NetEqualizer News! This month, we talk about our first round of beta testing our new release features, showcase our new website design, and discuss why caching alone will not solve your congestion issues! As always, feel free to pass this along to others who might be interested in NetEqualizer News.

A message from Art…

Whew! I am finally taking a breather after a busy and productive year – trying to get ready for the holidays and step back to assess all that I am thankful for. I want to take a moment to thank YOU, our customers, for making 2011 a great year for us! You are the reason we do all this and work so hard on making the NetEqualizer the best bandwidth controller out there.

We love it when we hear back from you – so if you have a story you would like to share with us of how we have helped you, let us know. Email me directly at art. I would love to hear from you!

In This Issue:

:: Update On Fall Release Features

:: DiffServ Priority Findings

:: New Website Design

:: Thank You!

:: Best Of The Blog

Our Website Contact Us NetEqualizer Demo Price List Join Our Mailing List

Update On

Fall Release Features

In our previous issue of NetEqualizer News, we previewed some of our exciting new features that are available in the Fall Release. The Fall Release is currently undergoing beta testing at various customer sites, but if you are interested in the GA release, let us know, and we’ll contact you when it’s available.

Please note, this release will be a quick update for anyone already on version 5.x.

Here is a brief update on some of those features with screenshots:

Email Notification

The Fall Release provides users with the ability to set an email account that the NetEqualizer can send alerts to. For example, users can set their account to be notified when IPv6 traffic exceeds 1%. Here is a screenshot from the email notification feature setup screen:

Setup Email Alerts in the NetEqualizer

IPv6 Visibility

The Fall Release also includes features that provide enhanced visibility to IPv6 traffic.

With this release, we now provide a connection table in the GUI that shows all of the IPv6 flows and their bandwidth consumption. We also provide a way to monitor your total IPv6 traffic from an historical perspective.

These two features provide useful data in order to better position your organization for the eventual shift to IPv6.

Here are some screenshots from the IPv6 interface in the NetEqualizer GUI:

IPv6 Traffic in the NetEqualizer

View Total IPv6 Traffic

For more information on the Fall Release, take a look at our Software Update Notes for version 5.5.

You can also visit our blog or contact us:

email sales -or-

call worldwide (303) 997-1300 x. 103 -or-

toll-free U.S.(800-918-2763).

DiffServ Priority Findings

In the Fall Release, NetEqualizer included a feature to give priority to traffic which had the ToS/DiffServ bit set to a non-zero value. This bit is supposed to signify that the traffic has priority on the Internet. This feature allows our customers to give priority to important traffic without having to set up a priority handling connection.

Through our research, however, we’ve discovered that sites like YouTube, in an attempt to receive priority access across the Internet, often set this bit for all traffic. Thus, with no control on who can set this bit, customers could find that their link is bogged down by too much requested priority.

Once you try it on your own network with the NetEqualizer, we want to hear about your experiences with this feature. How would you assess its effectiveness? Also, if you have experience using the DiffServ bit in other applications, how useful was it and in what ways? All feedback is welcome!

New Website Design

NetEqualizer is very excited to introduce our new website and design! The new website makes trying out the product, purchasing, and support that much easier.

Our new menus allow for quick navigation to common NetEqualizer tools and case studies. Be sure to check it out!

Thank You!

As we celebrate the holiday season, we at APconnections want to express our thanks to all of our customers!

To start, we’re pleased to introduce an expanded version of our NetEqualizer lifetime trade-in policy. Customers with NetEqualizers purchased four or more years ago qualify for a credit of 50 percent of the original unit’s purchase price (not including NSS, NHW, etc.) toward a new NetEqualizer!

This offer is an addition to our original lifetime trade-in policy guaranteeing that in the event of an unrepairable failure of a NetEqualizer unit, customers have the option to purchase a replacement unit at a 50 percent discount off the listed price.

While this policy is unique in its own right, we are also challenging tech-industry tradition by offering it on units purchased from authorized NetEqualizer resellers.

To learn more, or to get your trade-in started, contact us:

email sales -or-

call worldwide (303) 997-1300 x.103 -or-

toll-free U.S.(800-918-2763).

Best Of The Blog

Why Caching Alone Will Not Solve Your Congestion Issue

by Art Reisman – CTO – NetEqualizer

Editors Note:

The intent of this article to is to help set appropriate expectations of using a caching server on an uncontrolled Internet link. There are some great speed gains to be had with a caching server; however, caching alone will not remedy a heavily congested Internet connection

Are you going down the path of using a caching server (such as Squid) to decrease peak usage load on a congested Internet link?

You might be surprised to learn that Internet link congestion cannot be mitigated with a caching server alone. Contention can only be eliminated by:

1) Increasing bandwidth

2) Some form of bandwidth control

3) Or a combination of 1) and 2)

A common assumption about caching is that somehow you will be able to cache a large portion of common web content – such that a significant amount of your user traffic will not traverse your backbone to your provider. Unfortunately, caching a large portion of web content to attain a significant hit ratio is not practical, and here is why:

Lets say your Internet trunk delivers 100 megabits and is heavily saturated prior to implementing caching or a bandwidth-control solution. What happens when you add a caching server to the mix?

To keep reading, click here.