Software Technology for Network monitoring to measure performance of infrastructure service providers

Invented by Michael Gordon, Dlvr Inc

The Dlvr Inc invention works as follows

Background for Network monitoring to measure performance of infrastructure service providers

1. “1.

The present invention is generally related to adaptive streaming video. The present invention is more specifically related to performance management and measurement for video content delivery using adaptive streaming video protocols.

2. “2.

There are many digital service options available today. These include mobile apps and services as well as Internet websites, social networks, media and distribution services. Also, there are communications services and software and application services. Data services and electronic commerce services and payment services. Interactive services and other digital services. The majority of digital services are operated in a networked setting, whether it is a mobile network or the Internet. Networked environments are either public or private. They can also be a mix of both. Direct network communications, such as a computer user connecting to another computer, can also occur indirectly.

The infrastructure resources can include digital objects that are transmitted to or from the user device, among servers, or other devices supporting the digital service. They may also include compute resources, particularly those that are not part of the user device and that therefore, must be accessed remotely over the network; storage resources; data resources; network resources that connect various other resources and facilities in a networked setting, including mobile networks, the Internet, and private networks. Infrastructure resources include digital objects transmitted to or between the user’s device and the servers and other devices that support the service, compute resources (especially those that are not located on the device and are therefore accessed remotely over the network), storage resources, data resources, network resources connecting various other resources and services in a networking environment, such as mobile networks, private networks, and the Internet; image rendering resources, and other resources supporting the service. These resources can be made available in a limited number of instances or a single instance; they may be accessible to all users or some users or even only one user. They may also be managed and controlled by the service provider (for instance, servers operated by the service provider who host the Internet website), by a provider with an affiliation to the service provider (for exemple, a content network service provider which delivers website objects), by a provider with an affinity to the service provider (for examples, the mobile network of a user), or by a

The interconnection topology and performance of network links are not taken into account when determining the efficiency of the infrastructure resources. A user’s experience of a digital service can be characterized as a “weakest link”. A single unreliable or poor performing resource can degrade a user’s actual or perceived experience. For example, if a banner advertisement, an embedded image or another embedded page object takes too long to reach the user-device, it will appear to them that the whole web page is taking too

The complexity of the resources needed, the proliferation of service providers and infrastructure providers interconnected, the performance variability of the infrastructure and service providers and the lack of control of the necessary or unavoidable intermediary resource infrastructure and service providers and the volatility of the demand and utilization of infrastructure resources create a challenging technical environment in which digital services must operate.

A variety of commercially-available services have been developed in order to address different aspects of this technological environment. Cloud computing services such as EC2 and Cloud Servers by Rackspace provide highly available and scalable computing infrastructure. They include virtual servers that are addressed via IP addresses, just like physical servers but on demand. Cloud storage services such as S3 by Amazon Web Services or Orchestrate are available. Cloud Storage by Limelight Networks provides highly available and rapidly scalable data storage. Objects are addressed via Uniform Resource Locators instead of a file system or access method associated with the physical storage device. Akamai Technologies, Limelight Networks and other content delivery networks provide content delivery services (data and media objects) by assigning content servers through the resolution of hostnames contained in URLs. The IP addresses returned by the DNS infrastructure are intended to identify well-performing servers (normally not under extreme load conditions) that are located near the requesting point. This reduces network-related (by reducing the distance between networks and the number intermediate networks) as well as server-related (by increasing server resources and avoiding overloading the servers) Internap, Level 3 and other network optimization services reduce network-related delay by improving consistency, reducing network-induced latencies, selecting better routes and using private networks segments.

Each of these approaches has inherent limits.

Within and across these approaches, a service provider group may perform better in one set of conditions (for example, a particular set of user devices, a particular set of access networks, a particular set of access network types, such as mobile or broadband], a particular set of network and/or geographical locations, a particular set of object sizes or characteristics or resource characteristics, a particular set of object library sizes or access patterns, or resource access characteristics and a particular demand scenario), whereas another service provider might perform better in a different set of conditions. The performance of service providers under different technical conditions can change slowly or quickly, fluctuate regularly or infrequently, or be affected by unusual events. These may include sudden changes in aggregate or localized demand as well as outages, equipment and network failures, security breaches, or even sudden changes to the size and shape of objects. It can be challenging to test service provider performance objectively and fairly, particularly when the providers are aware that testing is taking place and/or if performance testing is detectable using technical methods. It is difficult to monitor service provider performance in real-world use (as distinct from testing), in detail and from the user’s point of view, across multiple providers, with different technical conditions.

To further complicate the technical environment, digital services often elect to distribute their use of a particular infrastructure service between two or more infrastructure providers. For example, they may simultaneously use two (or even more) content delivery networks in order to service content requests. They will then allocate a specific request to either one or the other. This is due to both technical and business reasons. A digital service can increase its leverage with service providers by using more than one. At the same time, it gains redundancy which allows it continue to operate if one service provider suffers a service outage. In many cases, the resources used are supplied by multiple originators. For example, when editorial content is combined with advertising, the content usually comes from the publisher, while the advertising content typically comes from an advertising agency, a network, a server or a service provider. The aggregate technical performance of a digital service, as well as the actual or perceived experience of the end user, is affected by a more complex set of technical factors. These include performance differences between infrastructure service providers and the originators. In these circumstances, the weakest-link condition can have a negative impact on the user experience overall or for a large portion of users.

Some of these challenges could be addressed partially by implementing software on the device of the user that collects technical performance data and adjusts the selection of infrastructure service providers and infrastructure services according to that data. The limitations of this approach are the limitations of the software environments that manufacturers implement on user devices and the complexity and other implications for digital service operators if they increase the amount of programming in the user device software and applications. The browsers that come with most mobile devices – such as the mini Safari built into Apple’s iOS or the mobile Chrome built into Android-certified phones – do not allow the installation of extensions. As a result, applications built on top of these browsers can only interact and cannot extend the functionality of the browser. The software development environments on many mobile devices, including iOS-based devices, and Android-certified devices, do not allow for low-level, direct interaction with the Transmission Control Protocol handling module. This means, for instance, that an iOS application cannot measure latency in connection, TCP loss or TCP jitter. In order to rely on software installed on the device, it would be necessary to rely on software which, for many devices, including most mobile devices, is limited in what it can observe and measure. The user’s explicit action to install a browser add-on is a major barrier to widespread, practical implementation. Implementing additional technical functions in an end-user application or via a web extension increases the amount programming code within the application.

The solution is to find a way of assigning (where appropriate), or delivering (where appropriate), resources required by digital services operating in a distributed environment. It is also necessary to assign infrastructure service provider tasks to resources required by digital services. This method should operate without adding software extensions to the apps on user devices or the browsers of user devices, measure and manage the performance of infrastructure resources and measure and manage the performance of multiple infrastructure service providers.

Adaptive bitrate stream can improve the user’s experience while streaming multimedia content such as video over a data network. For adaptive streaming, a video is usually encoded in multiple files. These are sometimes called renditions or variations, and each file represents the same video encoded with a different bitrate. The files are then segmented in a way that is consistent across all the files in the group. Each segment can be as short as a few seconds or even several seconds long. For example, the first segment in each variant file may contain the first 10 seconds of video and the second segment in each variant file the second 10 seconds. While this segmentation is consistent between the different bitrate files it does not mean that all segments must be of the same length. For example, a segment can last ten seconds, whereas a segment can last five seconds, whereas a segment can take six seconds, etc. The video player can then download the video file segment by segment and shift between different encoding bitrates while playing the video. This is dependent on how fast the segment files are being downloaded to the device, as well as other performance considerations. These can be affected either by network conditions or server performance. To maintain continuous playback the player may downshift from a high reference bitrate to a low bitrate if the network becomes congested. Later, when network performance and throughput improve, the player will upshift to the higher bitrate. Although playback does not stop, user experience may still be affected, since a change in the reference bitrate could cause noticeable variations in the video quality.

Generally, video files can be encoded in either a constant or variable way. When a video is encoded consistently, the bit rate is constant throughout the video. Therefore, when the video is split into segments, every segment will have a similar file size to the other segments. If a video is encoded in an inconsistent manner, then the bit rate may change during the video. For example, greater motion in one sequence of frames may result in a higher bitrate to maintain the visual consistency. Some adaptive streaming video implementations and specifications may support or work with variably encoded videos files.

Typically, to get the video segment files, the video player will first request a master manifest, also known as an index file or playlist. This is done by sending an HTTP GET for the master manifestation Uniform Resource Locator. The master manifest is usually a text document that contains a number of URLs. Each URL identifies a different variant manifest. These URLs can either be absolute URLs or relative URLs. Video players can request some or all variant manifest files using HTTP GET requests. Video players may also request HTTP headers for URLs for some or all variant manifests not requested fully (if any); they can confirm a file’s availability for download later and obtain information from the header. The text file of a variant manifest typically contains a number of URLs that identify video segments. These URLs may be absolute URLs or relative URLs; they are most commonly relative URLs. In addition to URLs and metadata, manifest files may also contain descriptive or control information. As the video player plays back the segments that are identified in the current variant manifest for live or linear video it will request a new variant manifest that should include additional URLs. In normal operation, this will continue until the player reaches a variant manifest that contains an “endlist tag” or similar indicator that the stream is at its end.

Various techniques” (e.g. systems, methods or computer-programs tangibly embedded in a nontransitory machine-readable medium) Herein are described techniques for generating and delivering manifest files for adaptive stream video. “In certain embodiments, the system for generating manifest files and providing them may include segment file servers as well as a manifest file server system that serves manifest files for an adaptive streaming video.

One or more embodiments can include techniques for delivering, measuring, and managing performance of on-demand videos to a device user in a networked setting, using adaptive streaming video delivery protocol, and utilizing a standard video playback component on the device user without adding additional software to the device user apps or browsers. The primary embodiment may refer to any of these embodiments, but it is important to note that this is only for reference and that there is no requirement that the primary is more important or prerequisite than the other embodiments.

One or more alternative embodiments can include techniques for delivering, measuring, and managing performance of linear video on a user’s device in a distributed environment. These embodiments could use adaptive streaming video delivery protocol and the standard video player component already present on the device, without adding additional software to the app or browser. “Any of these embodiments can be referred herein as a secondary embodiment. However, it should be understood this is only for reference.

The primary embodiment and the secondary embodiment can include systems and methods in which: an operator of a system of infrastructure component manages a character string that designates a service authorized to use that network; a network infrastructure component resolves hostname requests DNS resolution to direct URL requests of manifest files to specific components within that network; a network infrastructure component receives initial requests from devices for manifests, each manifest being associated with a video that the device is requesting to play; a network infrastructure component configures and returns one or more files to

The network receives requests from devices for manifests. Each manifest is linked to a video the device wants to play.