Problem #1: There may not be a single carrier who can provide connectivity in all the needed geograhpies. Although there are a number of large international carariers who provide connectivity to major cities of commerce around the world, the demands of a specific enterprise may have one or more offices outside their reach.
A variation on this problem is that an enterprise may have a well established long-standing relationship with a carrier that currently supplies data connectivity for global offices, but this carrier cannot meet the telepresence requirements for low latency, loss and jitter. Or perhaps they cannot meet those requirements in all geographies. So additional help is required.
Problem #2: In this scenario, the carrier of choice covers all but one or two of the sites well, but has to partner with another carrier for the remaining sites or has to run a dedicated link for a substantial geographic distance to cover that remaining site. The cost of that link may be substantially higher then the other connections and may push the cost of deployment for that site above an acceptable limit. This sometimes occurs in markets where telecommunications is still heavily government regulated and good pricing can only be achieved by using the government favored telecommunications provider.
The logical answer is to use partial solutions from two or three carriers and connect them together to provide the needed connectivity. But these connections are not ordinary peering connections; they must maintain the stringent quality requirements of the telepresence application. Most carriers do not have a good understanding of these requirements and do not have the mechanisms in place to guarantee quality across this connection. This is why there is no QoS solution on the Internet today.
I have seen three different network diagrams in the last few weeks that look like the canonical diagram below. In this case I show one carrier covering Europe and connecting to North America, and a second carrier covering Asia and connecting to North America. At first glance this diagram appears to do the job. But let's take a look at the challenges that this approach presents.
![](http://i.cmpnet.com/nojitter/ehk/july%2008/bartlett%20telepresence%20wan.png)
Bandwidth: Using this design, New York becomes a bandwidth concentration point. The WAN link from Provider A to New York must be able to carry the combined traffic from all telepresence suites in Europe into the New York office. Likewise the link from Provider B must carry all the traffic from Asia into New York. While this might be manageable at the scale of this drawing, as the enterprise expands its deployment, this bandwidth will become more expensive. If this bandwidth is limited, then it limits the number of simultaneous calls that can be placed between the two major geographies, which both limits the usefulness of the deployment and adds the complexity of managing the scheduling so as not to cause bandwidth conflicts. Furthermore, the bandwidth into New York has to be constantly reevaluated as the company deployment expands.
Bridge Location: The Multipoint Conferencing Unit (MCU) or bridge should be placed in the New York facility. If the NY facility can support the MCU, this works fine. If the MCU is placed elsewhere in the organization, the bandwidth demand of the bridge is also transiting the NY interconnect.
Quality of Service: The QoS for video traffic has to be maintained through the New York office connections. This is manageable from a design point of view but requires some careful planning. The SLA from Provider A may call for an AF41 DiffServ marking while the SLA from Provider B requires a CS4 marking. New York will have to do the translation. End-to-end jitter may be affected by the multiple transitions between LAN and WAN and requires careful attention. Worst case jitter and packet loss for this design is the sum of the statistics from each vendor.
Monitoring: A network monitoring solution must be deployed that can monitor the end-to-end paths of the video streams and can quickly determine which network component is causing the problem. Because there are multiple enterprise-owned components and multiple service providers, there is a high probability of finger-pointing between organizations. The role of the monitoring tool is to make those issues transparent and get the right team working on the problem as soon as possible.
Over the next few weeks, I will write about some innovative service providers who are developing solutions to directly address these issues.