MediaWarp has developed a plugin architecture that can rapidly respond to market needs with plugin modules that can be released between major release cycles. Moreover, they are customer extensible and modules can be stacked on top of one another to extend functionality. This allows operators to respond rapidly to ongoing changes in the Internet. Plugins can be downloaded while the system is in production which avoids system downtime. For example, MediaWarp has developed a specific YouTube plugin that converts all dynamic URLs to a standard URL using the metadata in the URL. As shown in the example, the plugin converts a rather long URL to a much shorter and static URL using the unique video ID metadata.  This enables the plugin to recognize that the different URLs actually refer to the same video and thereby to locate the unique video in the cache.

If YouTube changes the metadata in the future, MediaWarp could very easily modify the plugin to adapt to the change. Using simple interfaces, plugins can be used to modify incoming requests as well as proxied responses. A very rich and flexible cache policy framework can also be developed using plugins.

In summary, a plugin architecture is required to maintain the effectiveness of a caching solution by responding quickly to changes in content providers’ caching rules and the emergence of new ‘hot traffic’ domains.

Figure 1: Average Web Page Size and Number of Objects

As shown in Figure 1, while total page size has been increasing over the years, so has the total number of objects in a typical web page. In fact, the total number of objects in a typical web page has increased to ~85. Most of these objects are relatively small in size – between 20KB and 100KB. For instance, the www.youtube.com home page has multiple tens of thumbnail images, each of which is roughly 20KB in size.

Page download times are directly impacted by how quickly these tens of objects are downloaded to a device. Expedited delivery of small objects such as images is an important requirement from a Quality of Experience (QoE) perspective especially for mobile users. Mobile users have very little tolerance for a poor browsing experience and demand that pages load quickly with very little delay. According to a recent Gomez study, 58% of mobile device users expect sites to download as quickly as they would on their home computer; worse, a vast majority, 61% said that poor performance would make them less likely to visit the mobile site again. Page download times are also an important metric for ecommerce companies. By analyzing page abandonment data across more than 150 websites and 150 million page views, Gomez found that an increase in page download times from 2 to 6 seconds increased page abandonment rates by 25%. For ecommerce sites, the average impact of a 1-second delay results in a 7% reduction in conversions. For a $100,000/day ecommerce site, this implies that a one-second delay results in a $2.5 million in lost revenues in a year.

It is clear from the above discussion that for a transparent caching implementation to be effective, it needs to handle both small and large objects in an efficient fashion. While large object caching impacts bandwidth savings, caching of small objects has a direct beneficial impact on subscribers’ QoE, which is equally important.

Figure 1

As shown in Figure 1, requests for content (HTTP GET requests) are not sent upstream towards the origin server when the requested content is cached in the Transparent Cache. Instead, the requests are terminated at the Cache and cached content is served out in response. The origin server is completely unaware of requests made for the specific cached object, thereby disrupting the content provider’s business flows. In addition, there are scenarios where stale or objectionable content could be served by the cache while such content has already been removed at the origin.  For example, copyrighted content uploaded by users is frequently removed by YouTube. However, the implementation shown in Figure 1 will continue to serve copyrighted content directly from the cache, unaware that it has been removed from the origin server.

Figure 2

Another implementation that is not popular with content owners is shown in Figure 2. In this instance, HTTP GET requests are sent upstream towards the origin server, when the requested content is available in the Transparent Cache. While the response is being sent downstream by the origin server, the Transparent Cache generates a TCP CANCEL towards the origin server forcing the latter to stop transmission. Clearly, this approach wastes expensive bandwidth resources in the downstream direction.

Unlike either of these approaches, MediaWarp’s federated transparent caching implementation does not impact any application or service logic, meaning critical functions like authorization and click-through impressions are preserved so as not to impact Internet business models. In addition, care has been taken to ensure that stale content or content that has been removed from the Internet is not served from the cache.  This allows the entire caching system to more closely model the behavior of the content server, increasing transparency. MediaWarp’s implementation is completely compliant with the Digital Millennium Copyright Act (DMCA).

The operator is also provided with complete visibility in terms of caching performance and what types of content are being cached. To further increase the accuracy of the cache, the video is identified using the actual video content rather than the URL. This prevents misidentification of videos accessed by multiple or dynamic URLs.

For more information about the MediaWarp Transparent Caching Solution, contact VidScale.

As an example, the ability to federate content amongst multiple cards (deployed in a chassis configuration as shown in the figure) is very important in order to reduce overall network traffic and latency.

For instance, if a request for a specific piece of content is received by Card #1 (and if that content is not cached in Card #1), the latter should attempt to find out if the content is cached in any of the other cards in the chassis before forwarding the request upstream. Most existing transparent caching implementations are unable to perform this ‘discovery’ process – the request is forwarded upstream and the content is downloaded over the network needlessly, leading to increased network traffic and latency. In addition, such a silo implementation also results in lower cache hit ratios.

MediaWarp’s transparent caching implementation treats the entire cache memory distributed across all the cards in the chassis as a single ‘virtual store’. This ability to federate content increases the overall cache hit ratio that MediaWarp is able to deliver. MediaWarp’s solution is also flexible in that an arbitrary collection of nodes can be aggregated to form a cluster and federation can be enabled on this cluster. As an example, a cluster could either be the collection of all the cards in a chassis (as discussed in this example) or all network elements such as GGSN, PDN-Gateways that are physically co-located.