WHITE PAPER

© 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

Three choices. One goal.

Scale video without harming your network.

An enterprise content delivery network (eCDN) is a transport layer that optimizes the way streaming video is

distributed across corporate networks. By improving delivery performance, the eCDN minimizes the amount

of bandwidth consumed and reduces (or eliminates) network congestion. Audiences enjoy less latency and

buffering, faster video start times, and an overall higher quality, more reliable viewing experience.

The eCDN market is not terribly crowded with vendors, but it often appears

to be with various technologies all promising the same outcome. How do

you sort through the sales pitches and marketing claims? Will any eCDN

address your business needs—technically, operationally and financially—

and deliver the same quality user experience? If not, what is the right

solution for your company?

The most common eCDN technologies used for enterprise video are

multicast, caching and peer-to-peer (P2P) networking. Each one has unique

strengths and weaknesses. As always, it is important to choose the right

technology for the right business problem. Start by learning how each

technology works, then evaluate it based on your use cases and the

configuration of your network. A single eCDN technology rarely meets the

needs of most enterprises, and standardizing on one may require

compromises that could be difficult to manage. The good news is you can

easily mix and match eCDN technologies within the same network.

Protect Your Network

from Streaming Video

Guide to Selecting the Right eCDN

As individuals transition

back to the office, either full

or part-time, an ECDN is

critical to ensuring optimal

delivery of streaming video

without negatively impacting

other apps. More than 37%

of enterprises now use or

are planning to use, an

eCDN, up from 7.4% in

2018.

—Irwin Lazar,

Nemertes Research

“5 Keys to Video Streaming Success”

2 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

eCDN Technologies

Peer-to-Peer Networking

Peer-to-peer (P2P) networking originated with

content and file sharing at the birth of the

Internet, with Usenet often cited as the original

P2P network. When used with streaming video,

this distributed Publisher/Subscriber technology

creates a hierarchy of nodes to retrieve and

redistribute video segments from an origin video

source. A P2P network looks very much like an

inverted tree, with root nodes retrieving video

segments from the upstream origin server, and

downstream nodes retrieving video segments

from the upstream nodes, which in turn serve the

segments to nodes downstream from them.

In most P2P implementations, nodes perform two

functions: participating as member of the P2P

network and serving content to a local video

client. It is unusual for a node to just participate in

the P2P network without serving video. Therefore,

the nodes are the personal computers,

smartphones and tablets being used by people

watching the video. The P2P network is made up

of the viewing devices and almost nothing else.

This dual role of the P2P nodes is important when

considering what kind of video can be served.

When the video is a live stream, such as an

executive town hall, most viewers are watching

the event at the same time and, in fact, are seeing

the same timeframe of video at almost exactly the

same time. Therefore, most nodes will have the

same segments of the same video readily

available to share. In this mode, P2P is at its most

effective.

For on-demand video, viewers are rarely watching

the same video at the same time. And even if they

are, it is unlikely they will be viewing the same

timeframe of the video at the same time. Most

P2P networks are constructed dynamically by

nodes actively being used to watch a video. So, in

the case of video on demand (VOD), P2P is

opportunistic. To gain efficiencies, it needs more

than one person watching the same video at the

same time. And it needs a deep enough cache on

at least one node to allow it to meaningfully store

past video segments to serve to other node(s).

Multicast

Multicast was a technology contemplated when

IPv4 was first ratified in 1980. It took some time to

become fully formed with supporting protocols

but is now a mature and proven technology staple

of internetworking.

Multicast is a one-to-many and many-to-many

protocol. Senders and receivers in a multicast

group use a single destination IP address to

communicate. The network is responsible for

delivering packets from any sender in the group

simultaneously to all the receivers. For accuracy,

we note that multicast, at the fundamental level,

works for many protocols, not just IP.

In contrast, unicast traffic is a one-to-one

architecture where a sender sends data to one

receiver and broadcast traffic is a one-to-all

architecture where a source sends data to every

node on the network whether they intend to

receive it or not.

Multicast traffic is only sent to subnets with active

receivers. Therefore, in a very large network, the

multicast traffic does not traverse all network

segments, but only the segments needed to

ensure all group members receive the traffic. In

addition, multicast is highly efficient on the

network. Only one copy of the data needs to be

sent on each network segment, and every

3 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

multicast router and multicast-enabled switch

sends the multicast traffic only to segments that

have active multicast group members. Even if

multiple receivers are on a segment, only one

copy of the data is sent. All members receive and

read that same copy.

In contrast, in a unicast system, a copy is sent for

each receiver, so 100 receivers require 100 copies.

Because multicast is a push-based technology,

group members can only view videos that are

being sent, and as such, multicast is only

applicable to live and scheduled rebroadcast

events. It cannot serve video on demand.

Caching Video caching, like any other type of data caching,

temporarily stores frequently accessed videos or

video segments close to where viewers are

located on the network. When the first viewer

requests a video, the cache retrieves it from the

origin video source and stores a local copy. When

other viewers in the same location request the

same video, they receive it directly from the local

cache, not the source.

Caches are network services—often software

running on virtual machines, normally located in a

data center—and are persistently available for the

devices (personal computers, smartphones and

tablets) that need to use them. Because caching is

demand driven, like P2P, it works for both live and

video on demand. However, unlike P2P, the

constant availability of the cache makes it a better

solution for the opportunistic caching of video on

demand.

Designed for video, these caches store data in a

way that maximizes efficiency while minimizing

latency according to the type of video being

streamed. During live events, a large audience is

not only accessing a video at the same time, the

viewers are watching the same segments of the

video at essentially the same time. Time is of the

essence. Therefore, a small, fast cache that uses

memory (RAM) for storage is ideal because it can

retrieve video segments, store them, and serve

them in a very short amount of time.

With video on demand, viewership is more

staggered. Caches need to store multiple

segments, if not entire videos, to ensure data is

available for subsequent requests. A large cache

is the key for getting the best viewing experience

with the most bandwidth optimization, so caching

on disk works well.

In addition, for times when high demand for a

video is anticipated, many solutions allow

recorded video to be stored on the cache in

advance. This pre-positioning of video can be

done minutes, hours or even days before a video

is released or announced to ensure 100% of

requests are served from the cache.

Deployment Considerations Each eCDN technology requires different considerations for deployment that can be evaluated around a few

common aspects:

Client Infrastructure HTTP Streaming Internet/WAN

What needs to be

installed on user

devices to enable

the eCDN

What needs to be

deployed or configured

on the network or in

the data center

Optimizing delivery of

multiple video and

audio tracks

per stream

Efficiency

at the key network

bottlenecks

Client

Peer-to-Peer Networking

Peer-to-peer (P2P) traditionally required a client on the viewing devices. In most cases, the client was

deployable software that was either installed via the P2P vendor’s cloud service, pushed to devices through

desktop management processes, and/or accessible for download from an app store. Deploying software on

user devices is common practice at most companies.

The P2P client must run in the background all the time. Alternatively, users can be forced to activate the

client when they want to watch a video, which results in a poor user experience at best or, at worst, an

underutilization of the eCDN when they fail to invoke it. While the impact of a client running in the

background is quite small, it’s not zero and must be considered along with the security software running as

part of any corporate image.

Furthermore, as with all client software, versions for the different operating systems that need to be

supported may limit which devices can run the P2P client.

P2P has recently experienced a step forward in the area of rapid deployment with the emergence of

WebRTC P2P clients. WebRTC relies on inherent capabilities built into HTML5 web browsers that allow the

P2P client to be downloaded at the same time the video player is downloaded, making deployment

completely automated and invisible to the user. For this reason, WebRTC-based P2P solutions are

considered clientless. A discussion of the potential security and privacy vulnerabilities of WebRTC

notwithstanding, WebRTC also makes P2P universally applicable. Any device using a modern browser that

supports WebRTC can participate in a P2P network and realize the benefits of this technology approach.

4 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

5 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

Multicast

With the demise of Adobe Flash as a preferred streaming video solution, the ubiquity of multicast clients

that were part of Flash has also disappeared. No inherent multicast capability is built into the HTML5 video

players used today. And despite all operating systems supporting multicast for IP networks to work, no

standard approach to package video in multicast packets exists. Therefore, today’s multicast solutions

require a vendor-provided client install.

Like traditional P2P, the multicast client must run in the background all the time, so the presence of this

service must be considered along with the security software running as part of the corporate image.

Availability of client versions for different operating systems may limit which devices can run the multicast

client. At the time of publication, no multicast client exists for mobile operating systems.

Caching

Caching does not require any client installed on the viewing device, so all devices with an HTML5 browser

are supported.

If the caches are operating as forward proxies, a PAC file needs to be deployed to the client devices. The PAC

file is not a software installation, but rather a standard configuration file used locally on the device.

If the caches are operating as reverse proxies, no client work is necessary. Just the certificate deployed on

the caches must be signed by a trusted certificate authority (CA).

Infrastructure

Peer-to-Peer Networking

While peer-to-peer (P2P) networking has modest or no infrastructure

requirements, it does require either a cloud service or on-premises

centralized controller, so some infrastructure impact must be considered.

At the simplest level, the centralized controller needs to be discoverable,

which typically requires a DNS record added to the corporate DNS servers.

However, the larger impact is to the network itself.

The typical enterprise network design follows a hub and spoke model, with

services connected to the core and devices connected to the access layer.

For P2P, the traffic does not follow this optimal hub and spoke

architecture. Every node, except for the root nodes, receive traffic from an

access layer connected device.

The consequence is unpredictable latency and, more importantly, highly inefficient use of the LAN. Any

given node may be peered to another node that may be a) on the same access switch, b) on a different

access switch, but connected to the same distribution switch pair, or c) on an access switch that is

connected to a different distribution switch and interconnected at the core.

In the case of Wi-Fi, the consequence is predictable, but in the worst way. All traffic is routed via the core-

connected wireless controller. So for a given Wi-Fi connected node, even if it’s connected to an access point

87% of IT professionals say

it is “very important” or

“somewhat important” to

“distribute video without

harming the corporate

network.”

—Wainhouse Research

Survey Insight: Enterprise Streaming

Viewership and Adoption Trends –

North America Q4 2019

6 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

that is connected to the same access switch as its

upstream P2P node, all traffic from the upstream

node is sent to the core before being sent back to

the Wi-Fi connected device—the least efficient

journey using double the bandwidth. A low

density of Wi-Fi connected nodes will not really

induce a problem, but once the numbers start to

scale up the inefficiencies can have a real impact

on the network.

The same effect is true if the Wi-Fi connected P2P

node has downstream peers. However, the

problem can become even worse if the node’s

connect speed degrades. Because Wi-Fi is half

duplex, the upstream P2P node must first receive

the complete video segment. Then, once it

receives a request from a downstream node that

has waited for its turn to transmit, the upstream

node waits for its turn to transmit the segment to

the downstream node. On modern high-speed

Wi-Fi, these delays are not too bad, and the

segment can be quickly sent. For each

downstream node connected to that same

upstream node, the problem is compounded, and

at scale, it can have an impact.

Simply put, 100 Wi-Fi connected nodes on a P2P

network, accessing a 4 Mbps video, will generate

800 Mbps of network traffic, when only 400 Mbps

is required. An eCDN is about easing bandwidth

demands and reducing pressure on bottlenecks.

P2P, when used over Wi-Fi, can do just the

opposite.

Ethernet is not perfect either. Although the same

issue of segments repeatedly moving over the

distribution and core layers of the network

remains, the impact should be less as the packets

can follow the most optimal route.

Therefore, when a P2P eCDN is deployed at any

form of scale, it should allow the IT department to

choose preferred devices to act as upstream

nodes. The identification of preferred devices

should ensure enough access switches are served

by wired connections to minimize LAN

inefficiencies. For example, laptops that can easily

move from wired to wireless do not make good

preferred devices.

The easiest approach is to force Wi-Fi connected

P2P nodes to work only as leaf nodes, so they do

not have any downstream peers. But as the

percentage of leaf nodes on the P2P network

grows, the tree hierarchy flattens and the

efficiencies of the eCDN diminish. At best, every

peer-to-peer node receives a unique copy of the

same video segment that every node is receiving,

and these copies are moved backwards and

forwards over various layers of the corporate

network. At scale, it all makes for a challenging

environment for P2P.

Multicast

In addition to the client software, multicast requires a sender (server software) to work, two for redundancy.

The senders must have access to the Internet and obviously to the multicast-enabled network.

Multicast is a fundamental part of IP networks today. Used mostly for link-local service discovery, it works

well and requires little network treatment. When the multicast is expected to traverse an entire LAN or

WAN, however, network configuration is required.

For ethernet, this configuration is usually simple. You enable multicast on the IP routers/L2 switches, enable

IGMP snooping on the L2 switches, and configure a rendezvous point if using any-source multicast—all

standard capability on most IP routers. None of the configuration is complex. It just needs to be done if it is

not already and can normally be pushed down from network management.

7 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

Multicast gets more complex on Wi-Fi. The way Wi-Fi handles multicast and broadcast traffic is the crux of

the complexity. The multicast and broadcast speeds used by Wi-Fi exceed the bandwidth available to

reliably support video traffic. Fortunately, this limitation was recognized a long time ago, and now every

commercial-grade (and most consumer-grade) access points support unicasting of multicast traffic. It may

be counterintuitive, but it works, and when Wi-Fi is configured to unicast the multicast traffic, multicast

video can work perfectly. This configuration must be explicitly enabled as it is not the default for Wi-Fi

products.

Some products, like Cisco, also need to be configured to allow multicast traffic from the data center to the

access points with unicast over Wi-Fi to the connected devices. This configuration is the most efficient

method of carrying traffic in a thin access point architecture. As a result, two copies of each video segment

are sent over the LAN, one within the Wi-Fi tunnel and one directly on the LAN. But, because it’s multicast,

doubling the traffic is negligible. For a 4 Mbps video, 1,000 users over Wi-Fi and ethernet = 8 Mbps; 10,000

users = 8 Mbps; every person on the planet = 8 Mbps.

Caching

Deploying caches can be as simple as turning up

instances where they are needed, assuming

available compute (virtual or physical server) is

available. Where multiple caches are needed, DNS

round robin may be configured to facilitate

simplistic load balancing or a fully-fledged load

balancer. In both cases, these are standard

approaches for HTTP servers. In all cases, some

level of DNS configuration is required to direct the

client devices to the cache.

From a LAN impact perspective, as mentioned,

each client establishes a standard HTTP session

with the cache server to retrieve video segments.

As such, the LAN side network impact is largely

deterministic, and it does not require special

consideration other than ensuring the bandwidth

is available. Each user consumes 1x the amount

of video traffic, so a 4 Mbps video consumes

4 Mbps of LAN or Wi-Fi traffic. And, as the traffic is

all sourced from the data center or core attached

servers and virtual machines, the traffic flow

matches the forwarding design of the LAN and

Wi-Fi making it easy to traffic engineer.

The second consideration for caches is X.509

certificates. With all the bad actors on the

Internet, web browsers expect each website to

identify itself not only by IP address and DNS

name, both of which can be spoofed, but also by

an X.509 certificate from a trusted source, i.e., a

public certificate authority. With reverse proxy,

the browser believes the cache being accessed is

the origin server. Therefore, the certificate must

have a common name or subject alternative

name(s) that is the origin service(s), which means

a public certificate authority issued certificate

cannot be used. The company must produce its

own certificate and have that certificate trusted by

all the client devices. Superficially this seems like a

significant requirement, but most organizations

already have a certificate authority and deploy it

as a trusted certificate authority with their device

images. So, the process simply involves creating

the certificate and associating it with the cache

server, cluster of cache servers, or load balancer

for the cluster—which is all pretty normal.

When working in standard forward-proxy mode,

the certificate must validate the origin services

and the cache itself. Whatever DNS name is

assigned to the cache server or cluster of servers

needs to be included in the certificate, and all will

run smoothly.

Cache deployment becomes more challenging

when compute resources are not available for a

location and need to be deployed.

HTTP Streaming

Streaming HTTP video relies on tracks to carry

different information. Tracks contain encoded

media, including audio, video and subtitles. Video

tracks are used to support adaptive bitrate (ABR)

streaming by providing different video qualities to

accommodate variations in Internet bandwidth

and latency. Second, different audio and subtitle

tracks accommodate multiple languages and

closed captioning.

While ABR is highly desirable for video traversing

the Internet, it has much less value on a corporate

network where few packets are lost and traffic

engineering ensures bandwidth is available. The

availability of these multiple tracks, however, can

negatively impact the efficiency of the eCDN if not

properly handled by the implementation.

Peer-to-Peer Networking

Peer-to-peer (P2P) is a pull or demand-based

system. When a user wants to watch a video, the

browser, via the P2P client, fetches the required

video and audio segments. While this seems

superficially easy enough, potential complications

may exist that diminish the efficiency of the P2P

network.

The browser, based on the window size and

measured latency, may choose a particular

resolution or quality of video and request those

specific segments. Another viewer, peered to the

same P2P upstream node, may be watching in full

screen (different than the first viewer), so this

browser selects a different quality video than its

neighbor peer. As such, the same segment is

requested, but from a different video track. Now

the upstream node must have copies of both

video segments to cater for different resolutions.

And, of course, it’s possible that the upstream

peer has an altogether different resolution in

cache based on the requests received from its

own local browser.

In short, these three devices viewing the same

video are requesting three different tracks. The

P2P network could be adding no value at all

because every request must be passed up the

tree until the proper segment is found,

conceivably all the way back at the origin.

To bypass this inefficiency, administrative

configurations of the P2P solution may allow the

root peer to manipulate the playlist or manifest

such that only a single video track appears to be

available, ensuring all downstream browsers

request segments from the same track.

Multicast

As far as the content/video management system

(CMS) is concerned, the multicast sender is the

video client. It fetches the video, audio and closed

captioning segments and makes them available to

the subscribers. The subscribers never access the

CMS. They simply receive the information that is

made available on the multicast group.

In most situations, the multicast sender will

choose to request the best quality video track as

well as all the audio and subtitle tracks from the

origin. It will then rewrite the playlist or manifest

to match what it has selected and send those

options to the multicast group. In turn, browsers

will only see and play a single video option.

Caching

Caching is a pull or demand-based system. When

a user wants to watch a video, the browser

fetches the video segments from the cache based

on the window size and the latency.

8 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

9 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

When a second user wants to watch the same

video, but at a different display size, their browser

requests the same segment from a different video

track based on the quality options presented in

the playlist or manifest. If the cache does not have

this track already available, it fetches it.

This process continues, as required by browser

requests, possibly until all the different video

tracks are available in the cache. However,

because a cache supports hundreds of users or

more, even with this inefficiency it is able to serve

the majority of requests from the cache without

fetching new data from the origin. That said, a

stream that offers four different video tracks

reduces the cache’s WAN efficiency to one

quarter.

For this reason, a video cache should allow the

administrator to configure a preferred video

quality. The cache then uses this configuration to

rewrite the manifest or playlist, limiting the

number of video tracks the browser believes are

available, thereby ensuring a higher percentage of

requests are served from the cache.

Internet or WAN Connection

Peer-to-Peer Networking

Again, a key objective of the eCDN is to fix the

WAN congestion that may occur when hundreds

or thousands of users access the same video at

about the same time. Peer-to-peer (P2P)

networking, despite its LAN inefficiencies,

provides significant improvement compared to

not using an eCDN.

Much of the marketing material talks to high

scalability and high efficiency—up to 95%—a rate

typically achieved when P2P trees average around

20 nodes. However, published use cases typically

show efficiencies closer to 80% or P2P trees

averaging five nodes. In the context of eCDN,

these are modest improvements. For example, at

a location of 10,000 users accessing a 4 Mbps

video, 80% efficiency still means 8 Gbps of

Internet bandwidth necessary for the video,

above and beyond the bandwidth necessary for

normal work operations.

Multicast

For multicast, the only client fetching video is the

multicast sender. The amount of bandwidth

consumed on the Internet and WAN connection is

equal to one video stream, say 4 Mbps. Assuming

redundancy is a prudent decision (one primary

multicast sender and one backup) double the

bandwidth is consumed on the WAN, so 8 Mbps

total, to serve an unlimited number of viewers.

Worth noting, even when redundant senders are

used, traffic on the WAN is duplicated, but not the

LAN. Only one stream is sent to the LAN, with the

backup sender monitoring the primary to step in

when it fails.

Caching

WAN bandwidth consumption is usually

calculated as 1 x each cache server, i.e., each

cache server instance retrieves the segments they

need. However, clustering techniques create

efficiencies and better than 1x is possible.

Typically, software-based caches with appropriate

memory, storage and network connectivity can

support 500 to 1,000 users, which directly

correlates to WAN efficiencies. So, a location with

500 or fewer users will generate 4 Mbps of WAN

traffic when all users are accessing the same

4 Mbps video, netting a 99.8% WAN efficiency. As

each new cache is added, the WAN utilization

goes up by one, but the number of users doubles

as well.

10 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

Relative Strengths and Weaknesses

Peer-to-Peer Networking

Strengths

One of the strongest features of peer-to-peer (P2P) networking is that it needs virtually no infrastructure,

and in most locations, none at all. The only infrastructure a P2P network may need is a centralized controller

to coordinate the initiation of the P2P trees. The controller can be deployed in the cloud as easily as

anywhere else, since video traffic never passes through it. In fact, for P2P networks that self-form, no

controller is required. The nodes simply negotiate their hierarchy and the network forms as needed. This

lack of need for infrastructure has numerous benefits.

In a world that has moved from server farms to data centers to the cloud, the infrastructure at most

corporate locations is little more than the network: switches, access points and routers; and devices users

physically interact with, such as printers, displays and scanners. Outside of the large corporate facilities,

servers or spare compute devices are rarely available anymore, so P2P can work at the smallest of locations.

For the same reason, P2P networks are fast to deploy. As each viewer installs the P2P client on their device,

they can join or start a P2P network with little other work required. When using WebRTC P2P, no client

deployment is necessary and any device with a modern browser can participate in the peer network.

Another benefit of the “fetch” model of P2P is the ability to replay segments. When a user wants to jump

back in time, they can click the timeline and move to a point earlier in the video. The player in the browser

requests an older segment from the P2P client, and if it’s in local cache, it’s served directly. If not, the P2P

client asks the upstream peer, which checks its local cache, and either serves the segment or passes the

request upstream. This process continues until the request is successfully served, even if it makes it back to

the origin server, which will have the segment.

In a world where seemingly every corporate network is a snowflake—each with its own unique

architecture and methodology for distributing video—system administrators must thoroughly evaluate

their options and select the tools that will best smooth the flow of this data-intensive media.

—Wainhouse Research

Converting New Video Awareness into a Lasting Video Advantage

11 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

This requirement to support DVR capability for live events is not absolute across companies. Some

companies want employees watching live events in real time, so they prefer not to support features that

allow viewers to join late and rewind. Others, however, are happy to let employees watch events on their

terms, including jumping backwards and forwards through the video.

P2P, especially with WebRTC can be a great eCDN solution. Of course, it does have some limitations.

Weaknesses

The biggest weakness with P2P is its greatest strength. It relies on viewers—specifically their active viewing

devices—as the forwarding system. This weakness is exhibited in a number of ways:

• Potential for sub-optimal forwarding architecture

• Inefficient use of WAN bandwidth

• Topology instability

• Non-deterministic network impact

• High latency variation between nodes

• May require a client

P2P relies on the viewing devices to perform the forwarding of segments. Unlike infrastructure solutions,

viewers are users. They are not always at their desks or even in the office for the entire time a video event is

taking place. When a user disconnects from an event, perhaps to go to a meeting or leave the office, they

also disconnect from the P2P network. If they have downstream nodes, those nodes must now find new

upstream nodes or connect directly to the origin to get their segments.

Most P2P implementations will handle this instability transparently for users, but an unexpected surge of

demand over the WAN link can occur. When a node disconnects, its downstream nodes fall back to the

origin before finding suitable peers with adequate performance to accept new downstream nodes.

Since bandwidth consumption varies depending on the layout of the P2P tree, P2P is not deterministic.

Deterministic solutions are the friend of IT departments. When the IT department “knows” the bandwidth

demands, they can traffic engineer the network to ensure business-critical applications are not impacted by

live events. When P2P is used, overbuilding the network is the safest way to ensure unexpected P2P trees

don’t inadvertently impact other applications. Because the tree topology can change at any time as users

connect and disconnect, P2P makes bandwidth consumption on the network unpredictable.

Caution should be taken when using P2P on networks with Wi-Fi connected viewing devices. P2P can

actually consume more bandwidth than using no eCDN at all because of the half duplex nature of Wi-Fi and

the way traffic is routed through the wireless controller.

As mentioned, P2P is at its best when all viewers are accessing the same video at the same time. Therefore,

P2P is best used for live events and scheduled rebroadcasts. It is not as strong with video on demand since

user access is less orchestrated, reducing the opportunity for the benefits of P2P to be realized.

Summary

P2P—especially WebRTC-based P2P—can be deployed quickly, with minimal effort since no infrastructure is

required in most locations. By contrast, it is not very efficient as an eCDN, requires performance testing of

the network if Wi-Fi is prevalent, and has limited benefit for video on demand.

12 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

Multicast

Strengths

By far the strongest advantage of multicast is that a single segment of video is only sent once on any given

WAN, LAN or Wi-Fi segment, making it highly deterministic. A 4 Mbps video never consumes more than

4 Mbps on every segment on the entire network, irrespective of whether one or an infinite number of users

access the video.

The LAN and WAN efficiencies just get better as the number of users increase. For example, 1,000 users

watching a 4 Mbps video consume 4 Mbps on the WAN. With P2P, the same 1,000 users consume 800 Mbps

on the WAN. Multicast is an improvement of 796 Mbps or 99.5% more efficient than P2P at scale.

The deterministic nature of multicast is even more significant on networks with a heavy population of Wi-Fi

users. Once Wi-Fi has been configured for multicast traffic, the same exponential efficiencies are realized. In

contrast to P2P, the bandwidth impact is predictable (equal to one or two viewers total) and remains

consistent regardless of how many viewers are on the wireless network.

For a fully interconnected corporate network, the multicast sender only needs to be deployed in one central

place. The traffic can reach all locations via WAN links or VPN tunnels, so no local equipment is needed in

any given office that is connected to the data center/head office via WAN/VPN, which further builds on the

efficiency of multicast.

Weaknesses

The potential challenges of multicast include:

• Requires a client

• Delay in start times

• More latency

• Limited DVR capability

• Network validation/planning

• Behavior over Wi-Fi needs specific handling

Operating systems and HTML5 video players are not inherently multicast aware. Therefore, today’s

multicast solutions require client software to interface with the multicast protocol and receive video from

the multicast network.

13 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

One consequence of the multicast push architecture is slower video start times. A typical multicast

deployment will have a multicast sender connect to the origin and request video segments as if it is a video

player. Once the segment is downloaded and processed, which takes a few milliseconds, it can then be sent

to the multicast network. (This time consumed to fetch and process the video segment is identical for

caching and P2P.) When a viewer joins the video event, the player on their device starts up, which also

triggers the multicast receiver (the client software) to come online. The receiver aligns to the start of a

segment (which at worst is just under one segment from the current time in the video), buffers one or two

segments by default (which adds another one or two segments delay), and then serves the first complete

segment to the player. The player also buffers a few segments before playing them, another common

practice for all eCDNs, not just multicast.

Cumulatively, the multicast viewer may experience an average of four to six segments delay between

initiating the video and actually seeing it play. By contrast, in a store and forward request system like

caching or P2P, the player requests the last few complete segments, which may be multiple segments old.

These segments are retrieved in a few milliseconds and served to the player. Overall, users experience

faster start times, but they may be no closer to the real time of the video event (the most current segment)

than they would be on multicast.

The multicast experience can be improved by reducing the size of the dual buffers on the player and the

multicast receiver. Furthermore, efforts are continually underway to reduce the latency of streaming video

for live events, which will significantly improve the startup times and latency with multicast but will have less

impact on caching and P2P.

Also because of the push architecture, jumping back to an earlier time in a live event is challenging for

multicast. Akin to watching a broadcast television show, only the current video segment is available from the

eCDN. The eCDN isn’t designed as a storage mechanism the way it is with caching and P2P. Therefore, when

a multicast receiver gets a request to rewind, it does not have an upstream source with stored video

segments to query. The best it can do is serve video segments from its own cache. As a result, the viewer

can jump back to any point in the video they have already seen but not to a time before they joined the

event.

The final limitation of multicast as a push architecture is that the multicast stream must be enabled for

users to access it, which requires an explicit configuration as a step in the event setup process. This

configuration tells the multicast sender how to retrieve the playlist or manifest, the video, audio and closed

captioning tracks for the event, and indicates which multicast group (or channel) to use to send out the

stream.

Summary

Multicast is a robust solution for live events that is highly deterministic, scales infinitely and is especially

applicable for large enterprises. While it has a small incremental infrastructure requirement, it does take

network configuration, especially on Wi-Fi. Though once it’s configured, it works well. Multicast adds more

start-up latency than either of the other two eCDN solutions and requires a client to be deployed.

By far the strongest advantage of multicast is that a single segment of video is only sent once on any given

WAN, LAN or Wi-Fi segment, making it highly deterministic.

Caching

Strengths

The two standout benefits of caching are that it requires no client and it works equally well for both live and

on-demand video. As such, caching is the only eCDN that can legitimately claim to cover all streaming video

needs efficiently.

With caching in place, each viewing device establishes a point-to-point connection with the cache server and

directly requests the video segments it needs. The exchange appears as a normal HTTPS session as far as

the browser and player are concerned. Once a cache server is deployed, the cache is entirely in the network

infrastructure and largely invisible to the user. The lack of client is a massive benefit to the implementation.

Scaling cache eCDNs is a highly controllable artifact of the cache server or server farm. Cache servers

typically have capacity limits for slow storage, fast storage and number of client connections. These limits

are largely deterministic, so sizing a cache farm is usually a case of “doing the math” and deploying

accordingly.

Caches naturally lend themselves to replay, rewind and fast forward. A typical cache server can be

configured to keep a fast cache in memory for serving live video (close to real time is desirable) and a

slower, disk-based cache for longer term storage and playback of recorded video. It’s perfectly reasonable

for a cache to be able to hold an entire video in memory (disk or RAM), and thus users can jump to any point

in the history of the video. In this way, caches naturally look and behave just like the origin server.

Because caching works equally well for recorded video, some cache eCDNs

allow the unique option to precache video before it is needed. Doing so

ensures every request for the video segments are served entirely from the

cache and never from the origin server. This prepositioning is valuable to

protect business-critical applications when the release of a video is

expected to trigger a sudden spike in requests all at the same time—such as

an executive message or a mandatory training. By pushing the video into

cache during times of low network utilization, bandwidth is protected during

business hours and users still have a high-quality viewing experience.

Weaknesses

The biggest limitation of caching is that the cache server needs hardware to run on, and that hardware

usually needs to be behind the WAN link for the cache server to be truly effective. Therefore, depending on

Caching is the only eCDN

that can legitimately claim

to cover all streaming video

needs efficiently.

14 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

15 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

the configuration of the network, a location might need a physical or virtual server available to host the

cache software—a potential challenge for some companies as they move away from infrastructure.

With that said, many companies successfully deploy caches in data centers, because the bottleneck is the

Internet connection not the interoffice WAN links. In general, caching tends to be more ideal for larger

locations, where infrastructure is readily available.

Summary

Caching tends to be a simple set-it-and-forget-it type of eCDN. You size the caches, deploy them where you

need them, tell user devices how to reach them, and it just works—no client needed. Importantly, caching

also works well for both live events and video on demand. The network impact is relatively easy to work out,

and while not as deterministic as multicast, it is considerably better than P2P. Load-balancing, clustering and

certificates are the complex elements of caching, but these configurations are much the same as any load-

balanced or clustered service. The biggest drawback is the need to place the caches on the network close to

users, which depends entirely on the availability of infrastructure that can be used for this purpose.

One Size (Doesn’t) Fits All The overarching conclusion is that no eCDN technology represents deployment nirvana on its own. Instead,

an optimized eCDN combines technologies to address the different challenges presented by each location,

device and type of video.

For large buildings and campuses, the bandwidth optimization of multicast is far superior to both caching

and peer-to-peer (P2P) networking. The impact on the Internet connection, WAN links and the LAN is truly

negligible regardless of how many people are watching. Client software needs to be deployed to your

viewing devices, so you will need to coordinate with your desktop management team. Furthermore, the

network, especially Wi-Fi, must be configured correctly; however, multicast configuration is well understood

and not complex.

P2P networking is best suited for smaller offices and branches where

infrastructure does not exist and the number of users is modest. While P2P

can scale to build large networks, the WAN impact can rapidly become

unnecessarily high when large numbers of users are involved. Some P2P

solutions use WebRTC instead of a dedicated software client, which

minimizes deployment requirements, especially for remote locations. P2P

supports both live streaming and video on demand (VOD), but support for

VOD is rather limited and works only in some situations.

Like multicast and P2P, caching optimizes bandwidth for live video, but is

also the only reliable technology for VOD—such as pre-recorded training or

town hall replays—that many people will access, though not necessarily at

exactly the same time. Caching requires no client software, and all client

devices are supported, including mobile, making it a comprehensive option

for all viewing devices and scenarios.

Most enterprise use cases and requirements lead to a mix of all the above. As such, the most flexible eCDN

allows multicast wherever possible, augmented by caching at locations that can support the necessary

infrastructure—to provide multicast fallback and VOD—with P2P at remote locations that are not multicast

connected and do not have the ability to host a cache.

The overarching conclusion

is that no eCDN technology

represents deployment

nirvana on its own. Instead,

an optimized eCDN

combines technologies to

address the different

challenges presented by

each location, device and

type of video.

16 © 2020 Ramp Holdings, Inc. | info@rampecdn.com | rampecdn.com

Regardless of which eCDN technologies you choose to deploy, keep in mind your end-users cannot be

expected to select which one they will use if you make multiple available. The eCDN must be deployed in

cooperation with the enterprise video platform such that the decision which one to invoke is made

transparently, seamlessly and quickly with the end-user completely unaware.

Scale video without harming your network. Ramp can design a vendor-neutral video distribution network to fit your enterprise needs, regardless of

your network, use case or streaming platform.

Ramp is the first and only eCDN provider to offer all three technologies for enterprise video distribution—

multicasting, video caching and peer-to-peer networking. You can choose which approach—or combination

of eCDNs—works best for your enterprise.

Our vendor-neutral eCDNs eliminate network bandwidth issues created by enterprise streaming video.

Ramp protects your network to give viewers a flawless viewing experience.

About the Author Ramp is focused on helping every organization tap into the power of live and on-demand streaming video.

Our enterprise content delivery network (eCDN) solutions drastically reduce the bandwidth needed to

stream uninterrupted, high-quality video on corporate networks. Using multicasting, video caching, peer-to-

peer networking, or any combination, Ramp is the eCDN for all—all enterprises, all networks, all use cases,

and all streaming platforms. Ramp works with virtually any modern platform and is tightly integrated with

leading streaming video solutions. Our software deploys entirely behind your firewall for maximum security

and scales easily as demand for video grows. With centralized management, monitoring and insightful

analytics, you get unprecedented visibility into and control over network performance to deliver the highest-

quality viewer experience. Visit rampecdn.com for more information.