NetEqualizer News Blog

When talking to potential customers that do not have a NetEqualizer in place (yet), we often hear concerns from companies with recently installed VoIP systems that they are having trouble hearing incoming calls on their phones.  Typically, the root cause for this poor connection is that users are downloading files simultaneously with their VoIP calls.

Router technologies use a technology called DiffServ to enforce priority. Diffserv is reliable at preventing your outgoing Internet data users from interfering with your VoIP calls; however, most router technologies cannot prevent incoming Internet data traffic from overwhelming your incoming VoIP stream. This makes for the interesting dilemma on a call where they can hear you but you can’t hear them.

Fortunately, our bandwidth shaping technology, unlike a basic router, already uses techniques that allow an enterprise to prevent incoming data from overwhelming their VoIP/Skype calls.  We call this technology “Equalizing,” and we have recently enhanced our Equalizing algorithms (version 5.5 and above) such that specific priority for TOS/DiffServ bits will also be recognized.  DiffServ stands for “Differentiated Services Code Point (DSCP)” field and is analogous to the Type of Service (TOS) field.

The following FAQ addresses eleven common questions about our new TOS/DiffServ-aware technology:

1) Who can take advantage of this feature?
Anybody who needs to give priority to an incoming video or voice stream but does not know the source IP of the sender.

2) How do you control whether traffic coming into your network has a TOS/DiffServ bit enabled or not?
This is great mystery. Very little is written about this and how public Internet applications use the TOS bit. From experiments to-date, it seems that YouTube and VoIP providers are setting TOS bit(s) on their data streams.  This is the main reason why the initial NetEqualizer release 5.5 will be in beta test. It is an experimental release so our customers can turn on TOS/DiffServ priority and gather information on performance gains.

3) Who can set a TOS bit?
Almost any application that wants to can send out a stream with a TOS bit set; however, the typical home user does not have access to the TOS bit.

4) What are some of the Caveats with using the DiffServ/TOS Priority Feature?
In the initial beta release, we did not differentiate between types of TOS bits. There are several bits that can be set in this field by the sender that imply different types of quality. We decided to just treat this entire field as ON or OFF in our first release. Most networks that attempt multiple levels of priority are just not practical, as equipment lacks resolution in their processing to enforce different levels of priority. We decided to keep it simple; a stream either has priority or it doesn’t. Multiple levels of priority is more of an academic endeavor for wishful specifications.

5) How do you set the DiffServ/TOS Priority Feature from the NetEqualizer GUI?
Under “Modify Parameters” in the NetEqualizer set up screen:

TOS_ENABLED (on/off)

6) How do you know when a stream on your network has the DiffServ/TOS bit enabled?
From the “Active Connections” reporting screen on the NetEqualizer GUI, you will see a value of either on or off in the last column of the connection row.  “Off” indicates a TOS value of 0; “on” represents a TOS value greater than 0.

7) How does DiffServ/TOS bit priority compare with normal default equalizing?

To recap: A NetEqualizer bandwidth shaper naturally gives priority to VoIP and small web pages.

Now with the ability to provide priority specifically to streams with the TOS bit set, you can more tightly tune the NetEqualizer for VoIP priority, while at the same time provide priority for video.  The big variable will be just how much the TOS bit is used in public applications. On many of our field systems, we do have room to allow a little extra priority for the occasional video or Skype with video component. With the ability to honor TOS priority, your Internet link can grant priority to video without having to know the IP address of the sender or receiver.

8) What if an ISP allowed priority for a TOS bit and their users get wind of it?  Can they figure out a way to jump in front of the line giving ALL of their traffic priority?
We do not think this is likely at this time; the user would have to be aware of the practice of giving priority to TOS in a bandwidth controller to start, and they would then need a fairly sophisticated setup to change all of their applications to set this bit. A more realistic scenario is that video applications will by default already set this service.

9) With the lack of control over who can set a TOS bit, doesn’t this make this feature a little risky to turn on?
My analogy would be that we have a drug that promises to cure cancer and there might be some side effects (none of them will kill you, we promise), so give it a try and tell us what you find.

Note: An administrator has the ability to turn DiffServ/TOS priority on and off quickly, and take a look at the streams on the network. From our early tests over the Internet, we did see some public streams with this bit set, but it was only a small minority of them. We think the potential benefits far outweigh the risk.
Also, we will be working closely with all customers that participate in the Beta.  When Beta customers choose to turn  on DiffServ/TOS priority, we will be available to support them, and are happy to login and do some quick heuristics to assess results.  Our next release beyond the beta will make some sweeping optimizations.

10) Lets suppose all video from YouTube has the TOS bit set, would it be counter-productive to turn it on?
The worst case scenario here is that it would render your bandwidth shaping ineffective, which is no worse than running your network without your bandwidth shaper.  The best case scenario is that you have a mix of large downloads, BitTorrents, etc. that do not have the TOS bit set,  and so turning this feature on will make your video and VoIP better.

11) Many of the points discussed are specific to priority for video.  What about priority for VoIP – does it help with that?
Yes, it can, but for the most part normal equalizing already gives priority to VoIP.  In our next release, we expect to know if the VoIP providers and video providers are following guidelines for using different TOS bits. We could then give priority to VoIP all of the time, and especially on very tight networks, we could lower the HOGMIN threshold to further differentiate VoIP traffic. This point is rather technical, and if you have read this far it might be a good idea to pick up the phone and talk over these concepts with one of our network engineers.

Related Article
Other Solutions