How Kontiki Takes Live Video Broadcasting to the Next Level

Transcription

How Kontiki Takes Live Video Broadcasting to the Next Level
Technical White Paper
How Kontiki Takes Live Video Broadcasting to the Next Level
How Kontiki Takes Live Video Broadcasting
to the Next Level
Executive Summary
Today, there is a huge pent up demand for live video in the enterprise for everything
from executive & CEO updates to marketing communications to training. Live video
distribution remains a challenge primarily due to the constraints of the corporate
networks. Many companies deploy more networking hardware, like caching and video
streaming servers, in an attempt to handle the load on their global network, but this can
be costly and take months or years to implement, and ultimately may not provide for
ubiquitous video for all employes. Hardware-based infrastructure investments are typically
skewed towards larger corporate offices, leaving smaller remote offices and home-based
workers even more disconnected than usual from these exciting “live” events.
The foundation of Kontiki’s Enterprise Video Platform is our Delivery Management
System (DMS). The DMS overcomes the major challenges of streaming live video to
large numbers of users regardless of their location or how well connected they are.
The solution requires no infrastructure hardware investment and utilizes your existing
network infrastructure – no caching appliances to deploy and manage and no
streaming servers to distribute geographically. Simply deploy a small client
application on each end user’s PC and you’re ready to go. The Kontiki system uses a
centrally managed peer-assisted delivery model. The central management service
maintains a virtual network map of all the available client peers that are streaming the
live event and arranges communications between peers that are topologically close
to each other. This overcomes many of the problems associated with traditional live
streaming methods by moving the load from the Wide Area Network (WAN) to the Local
Area Network (LAN). The results show a significant improvement over the traditional
hardware solution, often resulting in only one copy of the stream going into each office
location regardless of the numbers of users in that office that are requesting that stream.
There are three important elements to the breakthrough technology that enables Kontiki
to stream high-quality live video to large audiences through your existing network
infrastructure:
• Topology awareness – Vast majority of the traffic travels over the LAN vs. the WAN
• Peer-Assisted Delivery – Every computer with a Kontiki software client is a potential
server
• Automatic stream selection – Each user automatically receives a bit rate that is
commencement with their available bandwidth
Technical White Paper
How Kontiki Takes Live Video Broadcasting to the Next Level
In addition to being the most efficient method of streaming live video across the
modern enterprise network, other benefits of the Kontiki solution include:
• Dramatic reduction in both upfront and ongoing maintenance costs
• A deployment time that is measured in weeks vs. months or years
• Unmatched end to end security of the live stream
• Great end user video streaming experience
• Leverages your existing network infrastructure
To summarize, Kontiki delivers high-quality, secure corporate video live, on-demand,
download, and push without the need for additional costly network hardware, data
connections or IT staffing. Kontiki’s end-to-end video delivery solution has all of the
robust functionality you need – multiple delivery options, email integration, portal
search and discover, security and analytics – all in a single complete suite available as
Managed Service or licensed software. With over 650,000 corporate computers enabled
worldwide, Kontiki has been used to securely publish, protect, deliver, and track digital
media content to employees of mid-size companies and large enterprises since 2000.
High Performance Content Delivery Technology
Kontiki’s goal is to deliver high quality live video to every desktop, regardless of
network topology and conditions. The Kontiki Delivery Protocol (KDP) is designed to
make highly efficient usage of distributed corporate networks.
Traditional distribution solutions attempt to solve the problem by deploying large
numbers of servers. But it becomes cost-prohibitive for large companies to put a server
in every location. Typically they can only get as close to the requesting computer as the
nearest data centre.
In contrast, the Kontiki DMS automatically enables clients to rapidly find peers
available to serve the desired stream that are as topologically close to the requesting
client as possible. Live video is served to the end user’s desktop across short network
chains from several peer servers simultaneously. A combination of server-side and
client-side intelligence enables this simultaneous short chain peer serving. The results
show a significant improvement on the traditional hardware solution, often resulting
in one copy of the stream going into each office location regardless of the numbers of
users in that office that are requesting that stream.
2
Technical White Paper
Traditional Distribution
How Kontiki Takes Live Video Broadcasting to the Next Level
Kontiki-powered Distribution
(more congested)
(less congested)
The Wide Area Network Problem
Worldwide enterprise networks, while employing many different types of technologies
such as MPLS VPN, are physically built on the hub and spoke model. In practice this
means locations have excellent connectivity inside the LAN, typically 100Mbit/sec to
1Gbit/sec, but have low bandwidth external connections to each other and back to central
data centers. While medium and large sized locations such as headquarter offices may
have external connections running at 155-422Mb/sec or higher, the vast majority of small
and mid-sized offices will have low speed and high latency connections such as ISDN
lines at 128kb/sec and ADSL/SDSL at 2-4Mb/sec that is shared by dozens and sometimes
hundreds of users.
For network architects, the primary goal when implementing a large-scale video
distribution system is that demand waves caused by large numbers of users attempting
to view video simultaneously will not impact the performance of the global network as
experienced by the employees.
Typical Distributed Enterprise Network
Small Offices
Large Offices
1Mb DSL
768Kb DSL
MPLS
VPN
2x 1Gb
10Gb
10Gb
4x 1Gb
10Gb Ethernet
1Gb
1Gb
512Kb DSL
Data Centre
3
Technical White Paper
How Kontiki Takes Live Video Broadcasting to the Next Level
Absorbing Demand Waves
The power of the peer network is that it acts as a “shock absorber” for the network
when many users want to watch a live or On-Demand video stream. For example,
when one user in a remote office chooses to start watching a stream, Kontiki will source
that stream over the WAN from a Kontiki central streaming server. But, regardless of
how many other users in that office want to watch that same stream, Kontiki will source
that stream from other Kontiki clients on the same LAN instead of going back over the
WAN for each user.
Distance Vector Optimization
Kontiki does not supply a random list of clients scattered all over the network, as is
often the case with consumer peer-to-peer file sharing systems. Requesting clients
of a video stream are provided with a list of the nearest peers that are currently
streaming the Live video. A centrally provisioned Directory Server that is configured
for the network layout and conditions manages this activity.
Distance Vector Optimization Illustration
Kontiki Hosted Services
Internet
Low Priority Peers
Medium Priority Peers
High Priority Peers
Requesting Client
The Directory Server uses a set of heuristics to automatically provide lists of peers
that are as close as possible to the requesting client. This decision is based on router
graph proximity, External IP address matches, IP prefix matches, Autonomous System
match, and Autonomous System path. Router graphs are built and maintained by
the Directory Server as it receives key information including traceroutes, external and
internal IP addresses, and other network information supplied by every online client. In
addition to server side peer allocation and prioritization, the Kontiki client software will
4
Technical White Paper
How Kontiki Takes Live Video Broadcasting to the Next Level
discover nearby peers that can serve it the Live stream by subnet broadcast as well as
“Intra-LAN” tests that measure line speed between a peer, response time of a peer, and
the number or router hops a peer is away from it. The Kontiki client also monitors the
response times and available bandwidth of each peer that is serving the stream, and
adaptively requests more data from the computers that provide the best throughput.
The clients in the grid will automatically optimize to focus on the computers that have
the topologically closest and least-congested connections, naturally adapting in real
time to avoid points of contention.
Central Command and Control
Kontiki enables our customer’s Network Engineering group to control and override all
the techniques the system uses for traffic routing via an easy to use central Network
Manager console. Also, many other client side configuration options such as
bandwidth utilization limits and CPU utilization thresholds can be modified via Kontiki’s
Network Manager console and those changes are automatically pushed out to all the
Kontiki clients.
End-to-End Security
Since the Kontiki platform relies on clients to serve content to other clients, an end to
end security framework must be in place to ensure only authorized users can request
and receive content, that information cannot be sniffed while travelling over the wire,
and that no malicious users or PCs with viruses can disrupt or alter the video content.
Access control
Kontiki enables the owner of the Live stream to protect the stream so only certain users
can participate in the Live event. Kontiki has built in support for any LDAP compliant
directory service as well as Active Directory. This allows content owners to pick and
choose groups of people from the corporation’s user directory that can access a particular stream.
For protected content, before a client or a Grid Server will serve a video stream to a client, it must validate that the requesting client is authorized to receive that video stream.
Kontiki uses a token mechanism for this authorization.
When a Live Event is created in the Kontiki DMS, a unique token is generated for that
particular stream. Then, anytime a clients wants to stream a Live event, that client must
first contact a central Authorization Server. The Authorization Server will only give the
client the token for the content requested if the client’s credentials are verified and the
authorization server verifies the end user is in the list of users that are allowed to view
the video.
When a client then goes to request the stream for either a Kontiki Central Server or another peer, the client will generate a one way hash of the token and send it to the client
or server it is requesting the content from. The recipient of the hashed token will then
generate a hash of the token it has and will only server content to the requesting client
if the hashes are identical. This ensures only authorized client can stream the video
even if their only sources of the stream are other clients.
5
Technical White Paper
How Kontiki Takes Live Video Broadcasting to the Next Level
Protocol Encryption
Transfers within the Kontiki DMS (whether between server and client, or from client to
client) are performed using either the Kontiki Delivery Protocol (KDP) or via SSL over
HTTP.
The KDP is based on industry standards for signatures and encryption. Each KDP
message and response is formatted in XML and signed and encrypted using the
following standards:
• Public/private key pairs are generated using RSA algorithms implemented by
the OpenSSL library. We use a 1032-bit key pair.
• Encryption is performed using the Blowfish algorithm implemented by the OpenSSL
library with a 128-bit symmetric key. (These keys are encrypted and transferred
using the PKI key pair. These 128-bit keys are generated on the fly and only used
temporarily during data transfers.)
• Signatures are based on the SHA-1 hash algorithm, implemented by the OpenSSL
library.
• Signature generation on the Java Web Application servers is implemented in a
standard Java Security Provider library.
All server and client certificates used by Kontiki DMS are X.509 compliant. The Kontiki
Certificate Authority signs one certificate for each DMS system. The system certificate
is used to generate a server certificate for each server. If a customer wishes to generate
its own server certificates, Kontiki will deliver the system certificate to the customer.
The client automatically generates its own public/private key pair on first run, using the
RSA algorithm.
Clients maintain a trust relationship with the servers in the same way web browsers
trust SSL-enabled websites. Every Kontiki client contains the public key of the Kontiki
Certificate Authority and uses that to check the servers are using certificates signed by
that CA at the top of the chain. After that has been checked the client encrypts every
message with the server’s public key and signs with its own private key.
Content Integrity
Clients do not trust each other. They exchange public keys so that they can encrypt the
data flowing between them. Then, for every block of a content that a client receives,
the client generates its own SHA-1 hash of that block then compares it against SHA-1
hash that is signed by a trusted central server. If any block fails a check, the client will
not source anymore data from that peer and will delete the bad blocks. Through this
method the system can guarantee a bit-perfect copy of every video stream received by
the client machine.
6
Technical White Paper
How Kontiki Takes Live Video Broadcasting to the Next Level
The End User Experience
The end user experience is of paramount importance when it comes to streaming Live
video. Although the Kontiki client simply wraps the standard Window Media player for
Live video playback, it extends the player’s capability by ensuring the user views the
appropriate bitrate stream based on the available WAN bandwidth at that user’s
location. This allows users to participate in a live event regardless of their WAN
connectivity limitations. For example, a Live Event can be configured to make three
different bitrates available – 1Mbps, 450Kbps, and 250kbps. Users in well connected
large offices may get the high end stream, while those in regional offices may get the
450Kbps stream, and while users in remote regions may get the 250kbps stream due
to their very constrained network links. The Kontiki client will automatically make the
correct choice without the user having to decide.
In addition to ensure the optimal stream is presented to each location, the built-in
client intelligence also monitors system performance in terms of CPU usage and
automatically backs off its own activity and slows down its service to other clients to
prevent any adverse impact to the local user’s desktop experience.
Scalability
The Kontiki DMS is highly reliable and scales to a very large user base. Featuring a
redundant, fault-tolerant architecture with multiple levels of failover and automatic
retry of content delivery by clients whenever necessary. Kontiki is currently supporting
implementations of over a million users in a single installation.
Setting up a Live Event via Kontiki
Once the Kontiki client is installed on the desktop of your end users, provisioning a live
event via Kontiki can be done in a few simple steps.
First, a Windows Media Encoder or a Window Media Streaming server that is the
originating source of the Live stream must be made available and must be configured
to allow the Kontiki central Grid Servers to pull the stream via HTTP. For redundancy,
a “standby” Encoder or Streaming Server should be configured to serve the stream
as well. If more than one bit rate of the stream is desired to suite various office
bandwidth conditions (e.g. 250kbps, 500kbps, & 1000kbps streams), then these should
be provisioned in the Encoder or Streaming Server.
Second, a “Live Event” must be created via the Kontiki Network Publisher application.
You’ll need to provide name, description, start time, end time as well as the primary and
secondary source URLs for each available bit rate. You can also protect the stream by
restrict it to a set of groups of users that can view it. Kontiki Network Publisher will then
return a special Kontiki URL (K-URL) which is a link to the newly created Live Event.
Finally, you’ll need to make the K-URL available to the invited users. The link can be sent
via e-mail, sent in a calendar invite, or embedded as a link on the Corporate Intranet.
7
Technical White Paper
How Kontiki Takes Live Video Broadcasting to the Next Level
Mechanics of a Live Event Delivery via Kontiki
When an end user clicks on K-URL, the Kontiki Client will decides the best bit rate to
stream based on each end user’s connectivity. Then the Kontiki Client will stream
from LAN peers or Kontiki central servers (Grid Servers) if no nearby peers are already
streaming it.
Kontiki’s Grid Server will initiate the stream from Windows Media Encoder or Window
Media Streaming Server when first client requests the stream. The Grid Server will pull
the stream from via HTTP. The Grid Server will automatically fall back to the “standby”
Encoder or Stream Server if the primary source fails. Note, Kontiki can also be used to
broadcast a Live Teleconferencing or Telepresence meeting to other viewers who are
invited to view the meeting.
Data flow for a Live Kontiki Event
1. Provision WM Encoder or WM Streaming server
• Optionally provision “standby” Encoder or Streaming Server
for redundancy
• Optionally provision multiple bit rates of the stream to suite various
office bandwidth conditions (e.g. 250kbps, 500kbps, & 1000kbps streams)
HTTP
HTTP
KDP
2. Create “Live Event” via Kontiki’s Network Publisher
• Specify name, description, start time, end time
• Specify primary and secondary source URLs for each bit rate
• Kontiki generates “K-URL”
KDP
HTTP
3. Send “K-URL” to end-users
4. User clicks on “K-URL”
• Client decides best bit rate to stream based in each user’s connectivity
• Client streams from LAN sources or Central Servers
• Kontiki’s Grid Server will initiate stream from Encoder or Streaming Server
when first client requests stream
HTTP
HTTP
KDP
Windows Media
Encoder
HTTP
KDP
HTTP
Kontiki Content
Servers
HTTP
KDP
KDP
KDP
KDP
HTTP
Windows Media
Streaming Server
HTTP
Conclusion
Kontiki’s Enterprise Video Platform has been used to deliver hundreds of millions of
hours of video -- helping our customers reduce their video (and large file) WAN traffic
by 90% or more, without deploying any hardware or upgrading their networks. With
Kontiki’s next-generation delivery solution, every employee can enjoy high-quality
video wherever they are in your network (corporate offices, small to medium branch
locations, home-based or traveling workers).
Visit www.Kontiki.com for more information.
TEL
408-215-6400
408-215-6401
EMAIL info@kontiki.com
FAX
© 2009 Kontiki, Inc. All rights reserved.
2009.12.16-WP010