Lack of standardization across QoS implementations makes for poor real-time app performance
With all the lip service paid to standardizing QoS techniques, one would think QoS would work well across carriers–but don’t bet on it says our NetForecast colleague John Bartlett. QoS implementations are not standardized enough across carriers to adequately satisfy the needs of discerning real-time application users without a lot of effort.
John recently helped a global corporation debug QoS problems with a multinational WAN consisting of many regional WANs deployed using regional carriers and interconnected by an international carrier. The company wanted to make real-time applications work across this two-tiered WAN architecture. The corporation’s network relies on the regional carriers to connect facilities within each region back to a regional data center, and the global carrier connects the regional data centers together. The following picture shows the scenario.
This type of architecture often reflects a corporation’s growth through acquisition. For example, a company does business primarily in one region (e.g., North America, Europe, Australia, Japan, etc.) and acquires another company to expand into another part of the world. Each acquired company already has a network, and rather than restructure the whole kit and caboodle, the company simply binds them together with this hierarchical approach.
While this may work relatively well for data applications, it does not cut it for voice and video communications. Here is why.
1. To make real-time applications perform well end to end, QoS policies must be consistent across all LANs, data centers, regional carriers, and the global carrier. While this sounds easy, it isn’t because of insufficient standardization among QoS deployments. A concerted effort by a central authority (which may not exist in an amalgamated company) is essential to ensure each region revamps to meet the corporate standard.
2. This network architecture suffers from excess latency due to extra hops introduced by redundant layers of switches and routers on the global paths. Adding hops to a voice or video conversation already slowed by long distances further degrades the user experience quality.
3. The unwieldy architecture causes bandwidth scaling problems at the local data centers. Whenever voice or video demand increases between regions due to increased collaboration, increased voice or video deployment, or upgrades for higher quality communications (e.g., HD voice or video), the bandwidth into and out of the data centers must also be increased. Again, a central authority must watch the entire network and adjust QoS bandwidth levels and/or deploy bandwidth to stay ahead of the bandwidth needs.
4. Finally, John tells us that this design is a bear to debug because there are so many different administrative domains involved in the path from one endpoint to the next.
In our next blog, we will share John’s insights into how to overcome these problems.
