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!
Every few months, we have a drawing to give away two roundtrip domestic airline tickets from
NetEqualizer News Blog 
QoS on the Internet — Can Class of Service Be Guaranteed?
July 24, 2008 — netequalizerMost quality of service (QoS) schemes today are implemented to give priority to voice or video data running in common over a data circuit. The trick used to ensure that certain types of data receive priority over others makes use of a type of service (TOS) bit. Simply put, this is just a special flag inside of an Internet packet that can be a 1 or a 0, with a 1 implying priority while a 0 implies normal treatment.
In order for the TOS bit scheme to work correctly, all routers along a path need to be aware of it. In a self-contained corporate network, an organization usually controls all routers along the data path and makes sure that this recognition occurs. For example, a multinational organization with a VoIP system most likely purchases dedicated links through a global provider like ATT. In this scenario, the company can configure all of their routers to give priority to QoS tagged traffic, and this will prevent something like a print server file from degrading an interoffice VoIP call.
However, this can be a very expensive process and may not be available to smaller businesses and organizations that do not have their own dedicated links. In any place where many customers share an Internet link which is not the nailed up point-to-point that you’d find within a corporate network, there is contention for resources. In these cases, guaranteeing class of service is more difficult. So, this begs the question, “How can you set a QoS bit and prioritize traffic on such a link?”
In general, the answer is that you can’t.
The reason is quite simple. Your provider to the Internet cloud — Time Warner, Comcast, Qwest, etc. — most likely does not look at or support TOS bits. You can set them if you want, but they will probably be ignored. There are exceptions to this rule, however, but your voice traffic traveling over the Internet cloud will in all likelihood get the same treatment as all other traffic.
The good news is that most providers have plenty of bandwidth on their backbones and your third party voice service such as Skype will be fine. I personally use a PBX in the sky called Aptela from my home office. It works fine until my son starts watching YouTube videos and then all of a sudden my calls get choppy.
The bottle neck for this type of outage is not your provider’s backbone, but rather the limited link coming into your office or your home. The easiest way to ensure that your Skype call does not crash is to self-regulate the use of other bandwidth intensive Internet services.
Considering all of this, NetEqualizer customers often ask, “How does the NetEqualizer/AirEqualizer do priority QOS?”
It is a very unique technology, but the answer is also very simple. First, you need to clear your head about the way QoS is typically done in the Cisco™ model using bit tagging and such.
In its default mode, the NetEqualizer/AirEqualizer treats all of your standard traffic as one big pool. When your network is busy, it constantly readjusts bandwidth allocation for users automatically. It does this by temporarily limiting the amount of bandwidth a large download (such as that often found with p2p file sharing) might be using in order to ensure greater response times for e-mail, chat, Web browsing, VoIP, and other everyday online activities.
So, essentially, the NetEqualizer/AirEqualizer is already providing one level of QoS in the default setup. However, users have the option of giving certain applications priority over others.
For example, when you tell the NetEqualizer/AirEqualizer to give specific priority to your video server, it automatically squeezes all the other users into a smaller pool and leaves the video server traffic alone. In essence, this reserves bandwidth for the video server at a higher priority than all of the generic users. When the video stream is not active, the generic data users are allowed to utilize more bandwidth, including that which had been preserved for video. Once the settings are in place, all of this is done automatically and in real time. The same could be done with VoIP and other priority applications.
In most cases, the only users that even realize this process is taking place are those who are running the non-prioritized applications that have typically slowed your network. For everyone else, it’s business as usual. So, as mentioned, QoS over the NetEqualizer/AirEqualizer is ultimately a very simple process, but also very effective. And, it’s all done without controversial bit tagging and deep packet inspection!
Share this:
Like this: