You Must Think Outside the Box to Bring QoS to the Cloud and Wireless Mesh Networks

December 10, 2012 — netequalizer

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

About 10 years ago, we had this idea for QoS across an Internet link. It was simple and elegant, and worked like a charm. Ten years later, as services spread out over the Internet cloud, our original techniques are more important than ever. You cannot provide QoS using TOS (diffserv) techniques over any public or semi public Internet link, but using our techniques we have proven the impossible is possible.

Why TOS bits don’t work over the Internet.

The main reason is that setting TOS bits are only effective when you control all sides of a conversation on a link, and this is not possible on most Internet links (think cloud computing and wireless mesh networks). For standard TOS services to work, you must control all the equipment in between the two end points. All it takes is one router in the path of a VoIP conversation to ignore a TOS bit, and its purpose becomes obsolete. Thus TOS bits for priority are really only practical inside a corporate LAN/WAN topology.

Look at the root cause of poor quality services and you will find alternative solutions.

Most people don’t realize the problem with congested VoIP, on any link, is due to the fact that their VoIP packets are getting crowded out by larger downloads and things like recreational video (this is also true for any interactive cloud access congestion). Often, the offending downloads are initiated by their own employees or users. A good behavior-based shaper will be able to favor VoIP streams over less essential data streams without any reliance on the sending party adhering to a TOS scheme.

How do we accomplish priority for VoIP?

We do this by monitoring all the streams on a link with one piece of equipment inserted anywhere in the congested link. In our current terminology, a stream consists of an IP (local), talking to another IP (remote Internet). When we see a large stream dominating the link, we step back and ask, is the link congested? Is that download crowding out other time-sensitive transactions such as VOIP? If the answer is yes to both questions, then we proactively take away some bandwidth from the offending stream. I know this sounds ridiculously simple, and does not seem plausible, but it works. It works very well and it works with just one device in the link irrespective of any other complex network engineering. It works with minimal set up. It works over MPLS links. I could go on and on, the only reason you have not heard of it is perhaps is that it goes against the grain of what most vendors are selling – and that is large orders for expensive high end routers using TOS bits.

Related article QoS over the Internet – is it possible?

Fast forward to our next release, how to provide QOS deep inside a cloud or mesh network where sending or receiving IP addresses are obfuscated.

Coming this winter we plan to improve upon our QoS techniques so we can drill down inside of Mesh and Cloud networks a bit better.

As the use of NAT, distributed across mesh networks, becomes more wide spread, and the bundling of services across cloud computing becomes more prevalent, one side effect has been that our stream based behavior shaping (QoS) is not as effective as it is when all IP addresses are visible (not masked behind a NAT/PAT device).

This is due to the fact that currently, we base our decision on a pair of IP’s talking to each other, but we do not consider the IP port numbers, and sometimes especially in a cloud or mesh network, services are trunked across a tunnel using the same IP. As these services get tunneled across a trunk, the data streams are bundled together using one common pair of IP’s and then the streams are broken out based on IP ports so they can be routed to their final destination. For example, in some cloud computing environments there is no way to differentiate the video stream within the tunnel coming from the cloud, from a smaller data access session. They can sometimes both be talking across the same set of IP’s to the cloud. In a normal open network we could slow the video (or in some cases give priority to it) by knowing the IP of the video server, and the IP of the receiving user,  but when the video server is buried within the tunnel sharing the IP’s of other services, our current equalizing (QOS techniques) become less effective.

Services within a tunnel, cloud, or mesh may be bundled using the same IPs, but they are often sorted out on different ports at the ends of the tunnel. With our new release coming this winter, we will start to look at streams as IP and port number, thus allowing for much greater resolution for QOS inside the Cloud and inside your mesh network. Stay tuned!

Posted in Bandwidth Management. Tags: , , , , , , , , , . Leave a Comment »

Eleven Tips to Improve VoIP & Video on the Internet Using NetEqualizer and DiffServ/TOS Bits

October 30, 2011 — netequalizer

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

Posted in Bandwidth Management. Tags: , , . 1 Comment »

Speeding Up Your Internet Connection Using a TOS Bit

August 10, 2011 — netequalizer

A TOS bit (Type Of Service bit) is a special bit within an IP packet that directs routers to give preferential treatment to selected packets. This sounds great, just set a bit and move to the front of the line for faster service. As always there are limitations.

How does one set a TOS bit?

It seems that only very special enterprise applications, like VoIP PBX’s, actually set and make use of TOS bits. Setting the actual bit is not all that difficult if you have an application that deals with the Network layer, but most commercial applications just send their data on to their local host computer clearing house for data, which in turn, puts the data into IP packets without a TOS bit set. After searching around for a while, I just don’t see any literature on being able to set a TOS bit at the application level. For example, there are several forums where people mention setting the TOS bit in Skype but nothing definitive on how to do it.

However, not to be discouraged, and being the hacker that I am, I could, with some work, make a little module to force every packet leaving my computer or wireless device standard with the TOS bit set. So why not package this up and sell it to the public as an Internet accelerator?

Well before I spend any time on it, I must consider the following:

Who enforces the priority for TOS packets?

This is a function of routers at the edge of your network, and all routers along the path to wherever the IP packet is going. Generally, this limits the effectiveness of using a TOS bit to networks that you control end-to-end. In other words, a consumer using a public Internet connection cannot rely on their provider to give any precedence to TOS bits; hence this feature is relegated to enterprise networks within a business or institution.

Incoming traffic generally cannot be controlled.

The subject of when you can and cannot control a TOS bit does get a bit more involved (pun intended). We have gone over it in more detail in a separate article.

Most of what you do is downloading.

So assuming that your Internet provider did give special treatment to incoming data (which it likely does not), such as video, downloads, and VoIP, the problem with my accelerator idea is that it could only set the TOS bit on data leaving your computer. Incoming TOS bits would have to be set by the sending server.

The moral of the story is that TOS bits that traverse the public Internet don’t have much of a chance in making a difference in your connection speed.

In conclusion, we are going to continue to study TOS bits to see where they might be beneficial and complement our behavior-based shaping (aka “equalizing”) technology.

Posted in Bandwidth Management, Network Speed. Tags: , , , , . 1 Comment »

Cisco Bandwidth Control for Education Networks

April 5, 2009 — netequalizer

The Cisco method is outlined below. However, you might also want to check out the NetEqualizer video filmed in front of the IT staffs at Eastern Michigan and Western Michigan Universities for a perspective on a simple alternate philosophy.

There is quite a bit of history with traffic classification  in the higher-ed market, so you can research some of the pros and cons of Layer 7 shaping before investing. You might also find some of these higher ed testimonials on the NetEqualizer worth reading.

The following was pulled from Cisco  marketing material specific to their bandwidth control solution for educational networks:

A fundamental requirement of any bandwidth control solution is the ability to apply QoS mechanisms. These mechanisms control the bandwidth of specific users and prioritize traffic to help ensure appropriate handling of delay-sensitive applications. QoS capabilities are essential for carrying delay-sensitive IP voice and video traffic over an institution’s ISP link, as well as for rate limiting recreational P2P traffic.
The Cisco SCE uses three levels of QoS:

Hierarchical bandwidth control: The Cisco SCE supports granular bandwidth control by allocating part of a link’s bandwidth for groups of specific application flows. Academic IT departments can define these groups according to categories such as “all P2P traffic,” “browsing and streaming traffic,” “all traffic flowing off net,” and so on. In addition, colleges and universities can use the Cisco SCE to enforce minimum and maximum bandwidth limits and priorities for the total traffic that is produced by a given user, as well as for the specific applications (browsing, gaming, and so on) in which the user engages. These advanced mechanisms are used in a tiered fashion.

Differentiated Services (DiffServ) queuing: Internet applications use DiffServ to help ensure that packets from delay-sensitive applications are prioritized over other packets. The Cisco SCE includes DiffServ-compliant transmit queues using “Best Effort Forwarding,” four levels of “Assured Forwarding,” and “Expedited Forwarding” for delay-sensitive applications.

DiffServ marking:  The Cisco SCE’s advanced classification capabilities can also be used for marking the IP type of service (ToS)/DiffServ codepoint (DSCP) byte of the associated traffic. Each flow or group of flows can be marked with a relevant DiffServ value based on the application or service. The next-hop Layer 3 device, such as a switch or router, then uses this marking to carry the delay-sensitive traffic appropriately. As a result, the Cisco SCE, crucial to the Cisco Bandwidth Control Solution, can serve as the ideal network element for classifying and marking application traffic for other DiffServ-enabled network elements.

Posted in News. Tags: , , , , , , . Leave a Comment »
%d bloggers like this: