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