ADAPTIVE PREDICTIVE DELIVERY OF INFORMATION
Background of the Invention
1. Field of the Invention
This invention relates to adaptive predictive delivery of information, including delivery of information at a time earlier than the information is requested, such as for use in an internetworking environment.
2. Related Art
In the World Wide Web, client devices (also called "web browsers") make requests for information from server devices (also called "web sites"), receive that information from the server devices, and deliver that information at those client devices to end-users. One problem when using the World Wide Web is that a rate of transfer of information from the server to the client is sometimes much less than desired. This problem is particularly acute when information to be transferred is requested at or about the same time by a relatively large number of clients.
A first known method is to deliver information to a relatively large number of clients on demand (i.e. immediately in response to a client request). This can be achieved by trying to respond to each demand individually. Devices and systems using this known method include mirrored web servers. While this known method generally achieves the result of delivering information more rapidly at a plurality of clients, it is still subject to several drawbacks. First, devices and systems using this method must have the information they deliver coordinated, so that when requested information is identical when served by any mirrored server. Second, devices and systems using this method use significant information transmittal
capacity when relatively large numbers of clients request the same information which often requires scaling up of the number of responding devices to meet demand.
A second known method for attempting to deliver information to a relatively large number of clients is to use a prearranged schedule for transmission of content. Clients then select to receive transmissions at the scheduled times. Thus, the service aggregates demand into a prearranged schedule that is convenient for the server. In an Internet protocol (IP) network this can be achieved using IP multicast, so that information can be duplicated by each router, conserving resources. Standard television broadcasting also fits this model of information delivery. While this known method generally achieves the result of delivering information to a plurality of clients, it is still subject to several drawbacks. First, it is generally only applicable in dealing with live broadcasts of information where the end client has no control over the presentation. Secondly, devices and systems that use this method use relatively fixed schedules, and do not consider information regarding known and projected demand for content amongst the client population.
Accordingly, it would be advantageous to provide a technique for transferring data from a source to a relatively large number of clients, that is not subject to the drawbacks of the known art. This can be achieved by using both known and predicted demand for content required at selected times in the future, selecting times earlier than when information is required and adaptively using transmission capacity, scheduling (i.e. timing of transmissions) and multicast grouping to deliver that information to a plurality of clients. Thus, reducing the total consumption of resources required to deliver a given content to all requesting clients and to deliver all content to all requesting clients.
Summary of the Invention
The invention provides a method and system for transferring data from a source to a plurality of clients that is not subject to the drawbacks of the known art.
This can be achieved by using both known and predicted/projected demand (herein referred to as "total demand") for content required at selected times in the future, selecting times earlier than when information is required and adaptively using transmission capacity, scheduling (i.e. timing of transmissions) and multicast grouping to deliver that information to a plurality of clients.
The invention provides an enabling technology for a wide variety of applications for delivery of content from a remote source to a plurality of clients, so as to obtain substantial advantages and capabilities that are novel and non-obvious in view of the known art. Examples described below primarily relate to the World Wide Web, but the invention is broadly applicable to many different types of systems in which delivery of preferred content is desired.
Brief Description of the Drawings
Figure 1 shows a block diagram of a portion of a system capable of transferring data from a source to a plurality of clients.
Figure 2 shows a process flow diagram of a method for operating a system as in figure 1.
Detailed Description of the Preferred Embodiment
In the following description, a preferred embodiment of the invention is described with regard to preferred process steps and data structures. Embodiments of the invention can be implemented using general-purpose processors or special purpose processors operating under program control, or other circuits, adapted to particular process steps and data structures described herein. Implementation of the process steps and data structures described herein would not require undue experimentation or further invention.
Lexicography
The following terms refer or relate to aspects of the invention as described below. The descriptions of general meanings of these terms are not intended to be limiting, only illustrative.
• client device, server device - In general, the phrase "client device" includes any device taking on the role of a client in a client-server relationship (such as an HTTP web client and web server). There is no particular requirement that client devices must be individual physical devices; they can each be a single device, a set of cooperating devices, a portion of a device, or some combination thereof. Similarly, the phrase "server device" includes any device taking on the role of a server in a client-server relationship. There is no particular requirement that server devices must be individual physical devices; they can each be a single device, a set of cooperating devices, a portion of a device, or some combination thereof.
• client, server - In general, the terms "client" and "server" refer to relationships between the client and the server, not necessarily to particular physical devices.
• source server - A server that contains the originating copy of a piece of content.
• scheduler - An element that controls the transfer of data between all servers and clients in a network so as to optimally deliver content from a server to a client. It is responsible for determining the timing of transmissions and optionally the formation of multicast groups.
• anticipated demand - Projected demand for content amongst a client population. This projection can be achieved by using the characteristics of the
content, the characteristics of the client population, and/or some combination of both.
• known demand - Demand for content which has been explicitly expressed by a client.
total demand - The combination of known demand amongst a client population for a given piece of content and anticipated/projected demand for content amongst a client population.
future demand - A general term meaning demand for content required at a collection of clients at some future time. Future demand could be anticipated demand, known demand, or total demand.
• multicast - A general term for any method that sends content from a source to multiple destinations.
• network resources - A general term for any property of an information delivery network that is available in a limited quantity. For example; link bandwidth, server cache capacity, and server transmission capacity.
• Adaptive scheduling - a method which uses the total demand, as defined above, to schedule the delivery of a set of content to a set of clients while minimizing the consumption of network resources.
As noted above, these descriptions of general meanings of these terms are not intended to be limiting, only illustrative. Other and further applications of the invention, including extensions of these terms and concepts, would be clear to those of ordinary skill in the art after perusing this application. These other and further applications are part of the scope and spirit of the invention, and would be clear to those of ordinary skill in the art, without further invention or undue experimentation.
System Elements
Figure 1 shows a block diagram of a portion of a system capable of transferring data from a source to a plurality of clients.
A system 100 includes a set of source servers 110, a set of destination devices (called herein "clients") 120, a communication network 130, and a scheduler 140.
Each server 110 is coupled to the communication network 130, and includes a processor, program and data memory, and mass storage, collectively disposed to maintain information content 111. The server 110 is capable of providing at least some portion of the content 111 in response to a request.
Similar to each server 110, each client 120 is coupled to the communication network 130, and includes a processor, program and data memory, and mass storage. The elements of each client 120 are collectively disposed to receive content 111, such as in response to a request.
A preferred embodiment is described herein with regard to "content"
111 that is presumed to include information that is relatively static (although the content 111 might be updated in response to time or in response to external events). However, in alternative embodiments, content 111 may be dynamically generated, such as in response to a state of a measurable system (such as for example telemetry or object-location circuits), in response to information in a database (such as for example stock prices or goods available for delivery), or in response to some combination or conjunction thereof.
In a preferred embodiment, the communication network 130 includes a store-and-forward network such as the Internet. In alternative embodiments, the communication network 130 may include alternative forms of communication, such
as an intranet, extranet, virtual private network, private or public switched network (such as a satellite or telephone system), direct communication links, or some other combination or conjunction thereof. In general, the scheduler 140 controls each server 110 and client 120 connected to the communication network 130. In an alternate embodiment the communication network 130 could itself be capable of receiving instructions from the scheduler 140 regarding sending, timing, or multicast or broadcast of information within the communication network 130.
Additionally, in alternate embodiments of the invention, it is contemplated that the communication network 130 may include any number of intermediate servers (not shown, but understood by one skilled in the art). These intermediate servers would function between the set of source servers 110 and the set of clients 120.
Similar to each server 110, the scheduler 140 is coupled to the communication network 130, and includes a processor, program and data memory, and mass storage, collectively disposed to perform the functions described herein.
The scheduler 140 includes a first input port 141, capable of receiving future demand information 142 regarding the communication network 130. As noted herein, future demand information 142 mcludes an identification of which portion of the content 111 (in a preferred embodiment, which of the elements forming a portion of the content 111) are intended to be delivered to which clients 120 by which times. The indicated times might be absolute time values (such as known time stamps), or might be relative time values (such as known offsets from a present time).
As noted herein, future demand information 142 might include either known demand information 143, which would refer to specific requests for at least a portion of the content 111 to be delivered to specific clients 120 at specific future times. For example, the schedule might glean future demand information 142 from requests by a set of clients 120 to receive a movie or other information scheduled to
be available at a known future time. The scheduler can then time delivery of the movie or other information and form multicast groups to "optimally" deliver the movie to the set of clients 120.
Alternatively, future demand information 142 might include anticipated demand information 144, which would refer to predicted likely requests for at least a portion of the content 111 to be delivered at predicted future times. In a preferred embodiment, the scheduler 140 determines a best prediction for anticipated demand information 144 in response to characteristics of the content 111, characteristics of clients 120, or characteristics of some combination or conjunction thereof.
• For a first example, if a specific portion of the content 111 includes a very popular movie, the scheduler 140 might determine anticipated demand information 144 in response to that information alone.
For a second example, if a specific portion of the content 111 includes a Horror movie and a specific client 120 is known by the scheduler 140 to like horror movies, the scheduler 140 might determine anticipated demand information 144 in response to the combination of those two facts.
For a third example, if a specific client 120 is known by the scheduler 140 to be in a specific time zone where the content 111 will be delivered at 3 :00 a.m., the scheduler 140 might determine anticipated demand information 144 in , response to that information alone.
In a preferred embodiment, sending and receiving of information between servers 110 and clients 120 may be adjusted by the scheduler 140 using the communication network 130 to optimize a selected objective measure. The scheduler, however 140, does not send or receive any of the information passing between the servers 110 and clients 120. The scheduler 140 controls the servers and
clients to adjust when information is sent in the communication network 130. Multicast grouping is controlled via the clients and servers.
Future demand information 142 input to the scheduler 140 represents anticipated and predicted demand for a set of future times, rather than a present time. Accordingly, the scheduler 140 can adjust timing of information delivery from servers 110, such as to times prior to when the information is actually needed at the client 120. Moreover, when timing of information delivery can be adjusted, the scheduler 140 can adjust multicast grouping to make optimal use of multicast delivery of information within the communication network 130.
For example, the scheduler 140 can receive requests to deliver a particular set of data (such as an online book containing hundreds of pages) to a relatively large number of clients 120. Without multicast grouping, the mere number of such requests might have the effect of overloading the server 110 having that portion of content 111. However, the scheduler 140, if it receives these requests in good time, can construct one or more multicast groups to allow the server 110 having that portion of content 111 to deliver the set of data to all interested clients 120 without undue load.
The scheduler 140 can be disposed to optimize to one or more of a set of different functions. For several examples, the scheduler 140 can attempt to optimize to one or more of, or some combination of, the following.
• Having been given a model of network link costs, the scheduler 140 can attempt to minimize total cost of sending information from servers 110 to clients 120.
• Having been given a model of bandwidth and latency between sub-elements of the communication network 130, the scheduler 140 can attempt to maximize
throughput (or to maximize bandwidth efficiency, or to minimize latency) in the communication network 130.
• Having been given a model of financial cost for early delivery, on-time delivery, and late delivery of information, the scheduler 140 can attempt to minimize total cost of sending information from servers 110 to clients 120. The scheduler 140 can alternatively or in addition attempt to minimize a difference between cost of sending information to clients 120 and a monetary value of those deliveries to those clients 120.
Method of Operation
Figure 2 shows a process flow diagram of a method for operating a system as in figure 1.
A method 200 includes a set of flow points and a set of steps. The system 100 performs the method 200. Although the method 200 is described serially, the steps of the method 200 can be performed by separate elements in conjunction or in parallel, whether asynchronously, in a pipelined manner, or otherwise. There is no particular requirement that the method 200 be performed in the same order in which this description lists the steps, except where so indicated.
At a flow point 210, the system 100 is in a quiescent state, and is ready to receive future demand information 142 regarding the communication network 130. As part of this quiescent state, the system 100 includes one or more servers 110 maintaining selected information for delivery upon request, and includes one or more clients 120 capable of requesting that selected information in response to activity local to those particular clients 120 (such as user action).
At a step 211, the scheduler 140 receives future demand information
142 regarding the communication network 130. As part of this step, in a preferred
embodiment, the scheduler 140 receives the future demand information 142 from one or more of, or some combination of, the following sources.
• The scheduler 140 can receive future demand information 142 from one or more servers 110. Each server 110 can determine future demand information
142 in response to known demand information 143 or in response to anticipated demand information 144. Each server 110 might determine known demand information 143 in response to request messages or information messages from one or more clients 120. Each server 110 might determine anticipated demand information 144 in response to information messages from one or more clients 110, in response to statistical information regarding past demand experience at that server 110, or some combination or conjunction thereof.
• The scheduler 140 can receive future demand information 142 from one or more clients 120. Each client 120 can determine future demand information 142 in response to known demand information 143 or in response to anticipated demand information 144. Each client 120 might determine known demand information 143 in response to local activity responsible for generating request messages from that particular client 120 to one or more servers 110. Each client 120 might determine anticipated demand information 144 in response to local activity of similar nature, in response to statistical information regarding past demand experience from that client 120, or some combination or conjunction thereof.
At a step 212, the scheduler 140 determines an optimal schedule which includes timing of information transfer, and grouping of transfers into multicasts for each of the servers and clients in the network, so as to satisfy future demand. As a part of this step the scheduler 140 attempts to optimize one or more functions as described with regard to figure 1. The scheduler 140 can be configured to optimize
delivery based on a plethora of criteria (for example, minimizing costs and maximizing use of available bandwidth).
At a step 213, the scheduler 140 (utilizing control information 146) directs servers 110, clients 120, and routers or switches in the communication network 130 to perform information transfers at selected times earlier than actual requests, so as to best satisfy the determination of the just-prior step.
At a step 214, the servers 110, clients 120, and routers or switches in the communication network 130 perform the information transfers directed by the scheduler, at the selected times (earlier than actual requests) selected by the scheduler 140.
At a step 215, the servers 110 and clients 120 maintain transferred information at receiving elements until the actual requests for information transfer are made.
At a step 216, the clients 120 deliver transferred information to receiving software elements when the actual requests for information transfer are made.
At a flow point 217, the system 100 is in a quiescent state, and is ready to repeat the steps between the flow point 210 and the flow point 217.
Generality of the Invention
The invention has general applicability to various fields of use, not necessarily related to the services described above. For example, these fields of use can include one or more of, or some combination of, the following:
• The invention is generally applicable to methods and systems where information is desired to be transferred at a time other than the time that information is requested, so that the information transfer is "time shifted" from the information request.
• The methods employed are equally applicable to wireless networks, cabled networks, and satellite networks.
Other and further applications of the invention in its most general form, will be clear to those skilled in the art after perusal of this application, and are within the scope and spirit of the invention.
Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those skilled in the art after perusal of this application.
Alternative Embodiments
Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those skilled in the art after perusal of this application.