Table Of Contents
Release Notes for Cisco Internet Streamer
These release notes covers the 2.1.1-b14 release.Revised: April 4, 2008, OL-15751-01
This information is in the release notes:
Release 2.1 of the Internet Streamer CDS introduces the Flash Media Streaming feature. The Flash Media Streaming feature offers the ability to stream and monitor flash media content using the Internet Streamer CDS.
Table 1 describes the enhancements to Internet Streamer CDS 2.1.
The CDS Internet Streaming runs on the CDE-100 and CDE-200 hardware models. The CDE-100 may run as the CDSM, while the CDE-200 may run as the Service Router or the Service Engine. See the Cisco Content Delivery Engine CDE-100 and CDE-200 Hardware Installation Guide for set up and installation procedures.
Limitations and Restrictions
This release contains the following limitations and restrictions:
•The Movie Streamer functionality is capable of MPEG1/2/4 and H.264 streaming over RTP/RTSP to a wide range of devices including PC, Mac, PDA, and cell phones, with 3GPP release 6 support for rate adaptation and capability exchange. However, this Movie Streamer functionality is available only on a demo and lab trial basis, and the software enforces a hard limit of 20 concurrent sessions. If you are interested in running the Movie Streamer in a field trial or production environment, please contact your Cisco account team.
•There is no NAT separating the CDEs from one another.
•Do not run the CDE with the cover off, this disrupts the fan air flow and causes overheating.
To maximize the content-delivery performance of a CDE-200, we recommend you do the following:
1. Use port channel for all client-facing traffic.
Configure interfaces number 3, 4, 5, and 6 (those on the quad-port Gigabit Ethernet Card) into a single port-bonding interface. Use this bonding channel, which provides instantaneous failover between ports, for all client-facing traffic. Use interfaces number 1 and 2 (the two on-board Ethernet ports) for intra-CDS traffic, such as management traffic, and configure these two interfaces either as standby or port-channel mode. Refer to the Cisco Internet Streamer CDS 2.0-2.1 Software Configuration Guide for detailed instruction.
2. Use the client IP address as the load balancing algorithm.
Assuming ether-channel (also known as port-channel) is used between the upstream router/switch and the SE for streaming real-time data, the ether-channel load balance algorithms on the upstream switch/router and the SE should be configured as "Src-ip" and "Destination IP" respectively. Using this configuration ensures session stickiness and general balanced load distribution based on clients' IP addresses. Also, distribute your client IP address space across multiple subnets so that the load balancing algorithm is effective in spreading the traffic among multiple ports.
3. Tune the TCP parameter.
On the CDE-200, execute the following commands once (this tunes the internal TCP configuration for better content delivery performance over HTTP):Config#tcp server-satelliteConfig#tcp client-satelliteConfig#write memory
4. For high-volume traffic, separate HTTP and WMT.
The CDE-200 performance has been optimized for HTTP and WMT bulk traffic, individually. While it is entirely workable to have mixed HTTP and WMT traffic flowing through a single CDE-200 simultaneously, the aggregate performance may not be as optimal as the case where the two traffic types are separate, especially when the traffic volume is high. So, if you have enough client WMT traffic to saturate a full CDE-200 capacity, you are recommended to provision a dedicated CDE-200 to handle WMT; and likewise for HTTP. In such cases, we do not recommended you mix the two traffic types on all CDE servers which could result in suboptimal aggregate performance and require more CDE-200 servers than usual.
5. For mixed traffic, turn on the HTTP bitrate pacing feature.
If your deployment must have Streamers handle HTTP and WMT traffic simultaneously, it is best that you configure the Streamer to limit each of its HTTP sessions below a certain bitrate (for example, 1Mbps, 5Mbps, or the typical speed of your client population). This prevents HTTP sessions from running at higher throughput than necessary, and disrupting the concurrent WMT streaming sessions on that Streamer. To turn on this pacing feature, use the HTTP bitrate field in the CDSM Delivery Service GUI page.
This release contains the following open caveats:
Cache Routing Module
The CacheRouter process gets restarted in rare longevity runs with mixed traffic. This may result in a core dump of the process. A core file is viewable in the cor_dir directory, by using the CLI.
This problem is likely to happen whenever there is a transition between active cache miss traffic and no traffic. A core dump and restart may not occur every time this situation is present.
No manual intervention is required. The CacheRouter process restarts instantly and is operational again. A few requests for cache miss traffic are redirected to the origin server. End clients should not be affected.
Flash Media Streaming Engine
When Flash Media Streaming is enabled, the fmsadmin process may leak memory every time the show statistics flash-media-streaming command is run either through the CLI or the CDSM GUI.
In order to minimize the memory leak, the periodic polling of Flash Media Streaming statistics has been disabled. Customers can still check statistics on Flash Media Streaming by issuing the show statistics flash-media-streaming command through the CLI or CDSM GUI.
Recovery of the memory leak can be accomplished by disabling and re-enabling the Flash Media Streaming engine.
Windows Media Engine
Playback of a VOD wsx playlist over HTTP fails when authentication is enabled on the Windows Media Server (origin server).
When NTLM or Negotiate authentication is enabled.
For VOD wsx playlists requiring authentication, use RTSP instead of HTTP.
For a cache miss scenario, the HTTP bitrate configured for the delivery service does not take effect. The client receives the content at the rate the Content Origin server sends the response.
Once the content is cached on the SE, for subsequent requests, which area cache hit, the bitrate takes effect. However, you may choose not to configure any bitrate for the delivery service, and let TCP congestion control determine the optimal rate of each HTTP progressive download session.
When running a Movie Streamer live program, Service Engines in the second level location may try to acquire the live stream directly from the Content Origin server.
There is no service or functionality impact on the CDS network. However, the load on the Content Origin server or encoders for the live source is increased.
This only happens when the Service Engines associated with the delivery service for the live program have experienced a failure or have been manually forced to reboot.
From the CDSM, disable and enable the delivery service for the live program. This action returns the CDS live program delivery tree back to normal.
In the CDSM, the Bytes Served graph for Movie Streamer shows "0" bytes.
Movie Streamer is enabled in the SE, and Movie Streamer content is streaming to clients.
Start a Telnet session to each participating SE, and use the show statistics rtsp server movie-streamer all command to view the Movie Streamer statistics.
When the Service Router is at peak load (approximately beyond 4000 to 8000 session set-ups a second), depending on the routing algorithms being used (consult the data sheet performance section), a few of the client requests may fail with 404 response. The maximum Service-Router performance as published in the data sheet is measured by ensuring that no more than 0.2% of the requests may result in 404 failure; and typically only 0.001% results in 404 failures.
If the client retries, it almost always gets successfully routed. The operator can further reduce the failure rate by adequately provisioning and deploying enough Service Router to absorb not only the average but also the peak workload. If the deployment is not provisioned properly, and the aggregate load on the Service Router goes beyond the published performance number (for example, 8000 HTTP or ASX redirections a second), then the number of 4xx failures may increase dramatically. However, if the load is at or below the published performance limit, then only a tiny faction fails.
After a reload, the CDNFS statistics are incorrect until the SE has synchronized all the content information in the system. The cached content database restoration can take a few hours if there are more than a million assets in the SE. During this time, content delivery, including cache hits, continues to work properly, buy the statistics are inaccurately displayed.
Allow the cache database to complete the restoration before checking the CDNFS statistics. Since database restoration can take even longer if there is constant and heavy traffic on the server, you are not recommended to direct too much traffic to a SE that has just reloaded.
Acquisition and Distribution
The error reported for manifest file parsing may not provide the exact location of the parsing error. It is usually off by a few lines.
There is no workaround. This is an inherited problem from the open-source XML parser and is a known problem of the parser.
If content deletion of preposition contents is occurring at the same time as newer contents are getting acquired, the content deletion may be very slow. This is noticeable when the number of assets >20 K.
There is no workaround.
When you execute the following config command in the SE to view the MIB, you receive an error.(config)#snmp-server view see ciscoServiceEngineMIB excluded
Use the object identifier (OID) instead of the symbolic name for the MIB subtree.
Caveats Not Caused by CDS Software
This release contains the following open caveats that are not caused by the CDS software:
Traffic loss occurs for a few seconds when a failover from primary to standby is triggered. This is an intrinsic property of the standby network interface mode.
Configure the port channel on both CDE and the connected switch, instead of standby interface. Port channel can recover interface failures in sub-seconds.
Windows Media Streaming
Client cannot use RTSPU when it is behind a NAT. This is an expected behavior as the client IP address is translated and not visible to server.
Configure the client to use RTSPT instead of RTSPU in its network configurations.
The Windows Media Player controls are enabled for live sessions. This is a Windows Media Player issue.
There is no workaround. This problem exists with or without CDS.
During playback of high bit-rate files, server streams the data at five times the rate of the bit-rate. This issue is seen even when the CDS is not used. It is Windows Media Player issue.
Turn off the fast cache feature on the server (Windows Media Server or CDS WMT), when serving high bitrate content (more than 780Kbps).
Windows Media Player cannot play media files with a size greater than or equal to 4GBytes that are progressively downloaded. This is a Windows Media Player issue as it does not work whether the Content Origin server is IIS or Apache and whether CDS is used.
There is no workaround.
When the origin server is Windows Media Server, and the client request causes a progressive download to occur, content playback fails in a hierarchical setup.
Make sure the file is streamed through WMT streaming.
For contents in the Content Origin server which are authenticated using NTLM, the Web-Engine download fails for those contents. It is commonly believed in the Internet community that supporting this for a proxy is a security hole, because we have multiple clients sharing same back end connection to Content Origin server, since NTLM is a connection-based authentication scheme. For this same reason web proxies like Squid and Apache proxy module do not support this nor does the CDS.
Do not use NTLM authentication on the Content Origin server.
Release 2.1.1 consists of many resolved issues since 2.0.3. Not all the resolved issues are mentioned here. The following list highlights the associated with customer deployment scenarios.
The CMS does not come up when the CDSM is reloaded and the CDSM GUI is not accessible (this happens extremely rarely). The following exception (or similar) is logged:06/18/2007 06:19:25.189(Local) [W] cdm(Scheduler): java.sql.SQLException: ERROR: Index sys_mess_time_idx is not a btree: java.sql.SQLException: ERROR: Index sys_mess_time_idx is not a btree
Execute the following command to run database maintenance:DT-612-10#cms database maintenance full ?
In performance tests, when 1000 concurrent HTTP sessions are ungracefully shutdown without sending the SE the normal TCP teardown messages, the SE takes up to 40 minutes to clean up all the zombie TCP sessions from its memory. The impact is that the memory resource and connections are temporarily held up by the zombie sessions in the period. If another 1000 to 2000 sessions are immediately sent to the SE before the previous 1000 sessions are cleaned up, it is possible that some of the new sessions are denied due to the 2000 concurrent sessions limit of web-engine.
There is no workaround. This is not a real deployment scenario because typical clients always tear down the session before exiting and the only time a client does not is when it is abruptly power-cycled. Therefore, it is extremely hard to have such an ungraceful tear-down happen in a synchronized fashion across thousands of sessions going to the same CDE. Considering that each session had been properly authorized by the operator's entitlement servers, it is also unlikely any malicious user can feasibly launch such an attack.
Under heavy stress, during mixed traffic of WMT and HTTP, the storage layer may report errors indicating corruption of storage metadata files. This is due to race conditions that occur when the content is being modified and looked at simultaneously.
These errors are transient and only result in a failure of a single request. New requests will not see this failure when the content is fully cached and the race condition does not exist.
SNMP Server authentication does not work if the privacy password is using SHA.
Use an MD5 based privacy password instead.
The following documents have been updated for this release:
•Cisco Internet Streamer CDS 2.0-2.1 Software Configuration Guide
•Cisco Internet Streamer 2.0-2.1 API Guide
•Cisco Content Delivery Engine 100/200/300/400 Hardware Installation Guide
•Regulatory Compliance and Safety Information for Cisco Content Delivery Engine 100/200/300/400
The following documents have been added for this release:
•Release Notes for Cisco Internet Streamer CDS 2.1
•Cisco Internet Streamer CDS 2.0-2.1 Quick Start Guide
Refer to the following documents for additional information about the Cisco Internet Streamer CDS 2.0-2.1:
•Cisco Content Delivery Engine 100/200/300/400 Hardware Installation Guide (OL-13478-03)
•Cisco Internet Streamer CDS 2.0-2.1 Software Configuration Guide (OL-13493-02)
•Cisco Internet Streamer CDS 2.0-2.1 Quick Start Guide (OL-15479-01)
•Cisco Internet Streamer CDS 2.0-2.1 API Guide (OL-14319-02)
•Release Notes for Cisco Internet Streamer CDS 2.0 (OL-13494-02)
•Release Notes for the Cisco Internet Streamer CDS 2.1 (OL-15751-01)
•Cisco Content Delivery System 2.x Documentation Roadmap (OL-13495-03)
•Regulatory Compliance and Safety Information for Cisco Content Delivery Engine 100/200/300/400 (78-18229-02)
The entire CDS software documentation suite is available on Cisco.com at:
The entire CDS hardware documentation suite is available on Cisco.com at:
Obtaining Documentation, Obtaining Support, and Security Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCDE, CCENT, Cisco Eos, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0803R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2008 Cisco Systems, Inc. All rights reserved.