Interested in delivering internal video to large, potentially massive audiences? Are you running into delivery issues not at the service level, but due to congestion caused at the ISP level?
IBM Cloud Video’s ECDN was created to address this need. However, large network setups have still seen congestion issues from their video applications due to multiple video distribution servers pulling videos into the enterprise network through a central ISP connection. To address the challenge resulted from hub-and-spoke network architectures IBM Cloud Video has introduced a multi-tiered distribution approach for ECDN. This creates a distribution hierarchy to further resolve congestion issues for some setups. In situations like a hub-and-spoke network, where there are central hubs that are gone through for Internet access, users might go through a regional server instead to remove strain that might originally have been placed on the hub.
Read on to learn more about this approach and the hub-and-spoke network setups that will benefit from it.
- ECDN and the need for multi-tiered distribution
- Challenge for a hub-and-spoke network
- Multi-tiered distribution for hub-and-spoke network
ECDN and the need for multi-tiered distribution
ECDN, short for Enterprise Content Delivery Network, is a network delivery solution for internal networks, including support for multiple locations. An ECDN edge server functions like a CDN server located at the internal network, installed as a virtual appliance. It is intended to reduce strain on the ISP (Internet service provider) connection that might be caused by video applications. A perfect example is an ECDN edge server installed at an office, decreasing the amount of strain on that local network by scaling delivery through using cached resources. So 60 users all trying to watch the same live stream, rather than having 60 separate requests to the ISP, are instead getting the stream from the ECDN node. As a result, what would have been 60 separate connections has been reduced to around 4, taking into account that the ECDN edge server is caching multi-bitrate versions (3-4) that are then being served out to end users.
The benefits of ECDN are well pronounced for a lot of setups, especially those with a large, concentrated audience. However, there are some setups where this can still introduce unnecessary strain, in-particular network environments where Internet access is “funneled” for security and control. A setup where the client has a data center or ISP link that sub offices have to connect through. In this case these offices create parallel, unnecessary connections to the Internet, even with ECDN edges in the mix. For example, 500 offices all trying to watch a live stream being broadcast would all go out individually to the ISP, causing congestion.
To address this, the product has been enhanced through the addition of a hierarchy. A way to mitigate the amount of traffic going to a central hub through multi-tiered distribution to alleviate some of the funneled congestion.
Challenge for a hub-and-spoke network
At its core, multi-tiered distribution is a huge benefit under certain company structures. An example would be a hub-and-spoke network environment, which is a site-to-site WAN (Wide Area Network) network topology.
This is where you take one site, for example a main office or a central IT location, that acts as a hub and connects other locations, known as spokes, to it. So each location’s use of the Internet has to transit through this central hub. In addition, network communication between spokes always travel through the hub as well.
A downside to this approach is the absence of alternative routes, as the spokes have to go through the hub. As a result, this can leave the system susceptible to congestion issues at the hub.
This congestion might be hard to visualize in the image example, where there are only a few spokes or branch offices. However, if we expand this to 400 users from even more spokes and all of them trying to go through the hub we can start to better visualize the congestion that could be caused. This can be especially true if these offices are trying to access content that is more resource intensive, such as video. A great example can be a company trying to broadcast an executive town hall, requiring the other offices to tune in and watch.
Multi-tiered distribution for hub-and-spoke network
Thankfully, multi-tiered distribution is built to remove this strain placed on the hub. This is done through creating a hierarchy distribution method. This works where top level servers, such as the Hub, get the stream first and then distributes to regional servers. Then the edge servers, located at the spokes, connect to these regional distribution servers.
Through adding an additional layer, we are greatly reducing the amount of strain on the WAN connection of the hub. This is best represented visually, showing a with and without scenario.
Directly above is a without scenario. In this case, let’s say during a town hall, each user from a spoke is reaching back to the hub, causing congestion. The solution is to introduce a multi-tiered distribution model, breaking up the amount of traffic going to the data center or hub.
Through adding another tier or layer, we have now reduced the strain on the hub. This is being achieved through regional servers, from IBM Cloud Video’s ECDN multi-tiered distribution method, acting as “middle men”. They will be sent the needed asset, in this case a live stream, which is then distributed to individual users at the various spoke locations. As a result, they no longer have to get this asset through the hub. The benefit, in the above example, is that we have reduced the strain on the hub by 75%, from 8 to 2. This is purely an example, though, and we could see even more benefit as the amount of spokes and users increases, such as 400 users from even more spokes calling upon a few regional servers.
In addition, this can be setup so that users can access just from the edge servers or even access from the regional servers as well. So in this case, the top layer where it comes in could be a head office. Mid tier, or the regional distribution servers, can be a local office or network. Finally the edges can be for the individual offices. However, employees might work directly at an office that contains a regional distribution server, and in this case can still access the needed content without having to reach out to the hub.
Once multi-tier distribution has been set up, a hierarchy view is presented in the cloud based dashboard. This showcases a structure, seen below, where the top-tier locations of distribution servers are marked in bold and displayed above the mid-tier and bottom-tier locations, the other offices where regional and edge servers are installed and might connect to the servers at their parent location. For example, an office might have a San Diego distribution server that works as the “middle man” to connect a San Francisco and an additional San Diego office, to avoid that use having to go to the central hub.
Support for multi-tiered content distribution marks off another network setup which is now addressed through IBM Cloud Video’s ECDN service. It continues the expansion of setups where the implementation of ECDN can relieve potential congestion issues that might be caused by video applications, usually due to live streaming which can cause large audiences to all access content at the same time.
Curious how the service will continue to evolve to meet even more network setups? Read our Internal Video Delivery eBook to get an idea, which encompasses a variety of different setups beyond one where unicast (transmission of an audiovisual signal to a single recipient) might be utilized as well.