Methods and systems for streaming media data over a content delivery network

Abstract

The present document describes a method (900) for establishing control information for a control policy of a client (102) for streaming data (103) from at least one server (101, 701). The method (900) comprises performing (901) a message passing process between a server agent of the server (101, 701) and a client agent of the client (102), in order to iteratively establish control information. Furthermore, the method (900) comprises generating (902) a convergence event for the message passing process to indicate that the control information has been established.

Claims

1. A method for establishing control information for a control policy of a client for streaming data from a server to the client; wherein the method comprises, performing a message passing process between a server agent of the server and a client agent of the client in order to iteratively establish control information; and generating a convergence event for the message passing process to indicate that the control information has been established; wherein performing the message passing process comprises, within a given iteration, sending server metadata from the server agent to the client agent; wherein the server metadata at the given iteration depends on client metadata sent from the client agent to the server agent, at a given iteration; wherein the server metadata is determined, by the server agent, in dependency of a total quantity of the resource to be allocated to a plurality of clients for streaming data by solving a minimization problem based on a server cost function, and wherein the server metadata is indicative of the allocated quantity of the resource which has been allocated to the client for streaming the data; and sending client metadata from the client agent to the server agent; wherein the client metadata at the given iteration depends on the server metadata sent from the server agent to the client agent at the previous iteration, wherein the client metadata are determined, by the client agent, based on a client utility function; wherein the client utility function indicates a utility for the client of the data received by the client, as a function of a quantity of the resource that has been allocated to the client for streaming the data; a requested quantity of the resource, requested by the client, is determined, by the client agent, by minimizing a cost function which comprises a first term being dependent on an absolute or a squared deviation of the requested quantity of the resource from the allocated quantity of the resource; a second term comprising a complement of the client utility function; and a weighted sum of the first term and the second term; and wherein the client metadata is indicative of the determined requested quantity of the resource.

2. The method of claim 1, wherein the allocated quantity of the resource is determined based on the requested quantity of the resource.

3. The method of claim 1, wherein the control information is indicative of or comprises a quantity of a resource that has been allocated to the client for streaming the data.

4. The method of claim 1, wherein the method comprises, performing a pairwise message passing process between the server agent of the server and client agents of the plurality of clients, in order to iteratively establish control information for each of the plurality of clients; and the plurality of clients compete for the total quantity of the resource available for streaming the data from the server.

5. The method of claim 1, wherein the method comprises, performing a pairwise message passing process between server agents of a plurality of servers and the client agent of the client, in order to iteratively establish control information for control policies of the client for streaming the data from each of the plurality of servers, wherein the plurality of servers include the server; and streaming different fractions of an overall media stream from the different servers based on the established control information for the different servers, respectively.

6. A method for establishing control information for a control policy of a client for streaming data from a server to the client; the method comprises, receiving , by a server agent, client metadata; wherein the client metadata is indicative of a requested quantity of a resource requested by the client for streaming the data from the server; determining , by the server agent, server metadata based on the received client metadata and in dependency of a total quantity of the resource to be allocated to a plurality of clients for streaming data by solving a minimization problem based on a server cost function; the server metadata is indicative of an allocated quantity of the resource allocated to the client for streaming the data from the server; sending , by the server agent, the server metadata; and repeating the receiving , determining and sending steps until occurrence of a convergence event; the convergence event indicates that control information for the control policy of the client for streaming the data from the server has been established based on the iterative receiving of client metadata and sending of server metadata.

7. A method for establishing control information for a control policy of a client for streaming data from a server to the client; the method comprises, receiving, by a client agent, server metadata; the server metadata is indicative of an allocated quantity of a resource allocated to the client for streaming the data from the server; determining, by the client agent, client metadata based on the server metadata including determining a requested quantity of the resource by minimizing a cost function which comprises i. a first term being dependent on an absolute or a squared deviation of the requested quantity of the resource from the allocated quantity of the resource; and ii. a second term comprising a complement of a client utility function, wherein the client utility function indicates a utility for the client of the data received by the client, as a function of a quantity of the resource that has been allocated to the client for streaming the data; iii. a weighted sum of the first term and the second term; wherein the client metadata is indicative of the requested quantity of the resource requested by the client for streaming the data from the server; sending, by the client agent, the client metadata; and repeating the receiving , determining and sending steps until occurrence of a convergence event; wherein the convergence event indicates that control information for the control policy of the client for streaming the data from the server has been established based on the iterative receiving of server metadata and sending of client metadata.

8. A non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processors of a server of a content delivery network, the one or more programs including instructions for: receiving client metadata; wherein the client metadata is indicative of a requested quantity of a resource requested by a client for streaming the data from the server; determining server metadata based on the received client metadata and in dependency of a total quantity of the resource to be allocated to a plurality of clients for streaming data by solving a minimization problem based on a server cost function; wherein the server metadata is indicative of an allocated quantity of the resource allocated to the client for streaming the data from the server; sending the server metadata; and repeating receiving, determining and sending until occurrence of a convergence event; wherein the convergence event indicates that control information for a control policy of the client for streaming the data from the server has been established based on the iterative receiving of client metadata and sending of server metadata.

9. A non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processors of a client device of a content delivery network, the one or more programs including instructions for: receiving server metadata; wherein the server metadata is indicative of an allocated quantity of a resource allocated to the client device for streaming the data from a server; determining client metadata based on the server metadata including determining a requested quantity of the resource by minimizing a cost function which comprises i. a first term being dependent on an absolute or a squared deviation of the requested quantity of the resource from the allocated quantity of the resource; and ii. a second term comprising a complement of a client utility function, wherein the client utility function indicates a utility for the client device of the data received by the client device, as a function of a quantity of the resource that has been allocated to the client device for streaming the data; iii. a weighted sum of the first term and the second term wherein the client metadata is indicative of the requested quantity of the resource requested by the client device for streaming the data from the server; sending the client metadata; and repeating receiving, determining and sending until occurrence of a convergence event; wherein the convergence event indicates that control information for a control policy of the client device for streaming the data from the server has been established based on the iterative receiving of server metadata and sending of client metadata.

Description

SHORT DESCRIPTION OF THE FIGURES

(1) The invention is explained below in an exemplary manner with reference to the accompanying drawings, wherein

(2) FIG. 1 shows a block diagram of an example content delivery network;

(3) FIG. 2a shows a flow chart of an example method for streaming data performed by a client of a content delivery network:

(4) FIG. 2b shows a processing unit of a client;

(5) FIGS. 3a and 3b show flow charts of example methods for streaming data performed by a server of a content delivery network;

(6) FIG. 4a shows example client cost functions;

(7) FIG. 4b shows example client utility functions;

(8) FIGS. 5a to 5c show example communication channels between a server and multiple clients;

(9) FIGS. 6a and 6b show example bottlenecks within a content delivery network;

(10) FIG. 7a shows multiple content delivery networks serving one or more joint clients;

(11) FIGS. 7b and 7c shows example communication channels for a message passing process in a multi-server scenario;

(12) FIG. 8a shows example parameters of a control policy of a client without using a message passing scheme;

(13) FIG. 8b shows example parameters of a control policy of a client using a message passing scheme; and

(14) FIGS. 9a to 9c show example flow charts of methods for establishing control information for streaming data within a content delivery network.

DETAILED DESCRIPTION

(15) As outlined above, the present document addresses the technical problem of increasing the QoE for streaming data within a content delivery network. In particular, the present document is directed at increasing the average QoE for a plurality of clients within a content delivery network. In this context, FIG. 1 shows a block diagram of a content delivery network 100 which comprises a server 101 and a plurality of clients 102. The server 101 is configured to send an individual data stream or an individual stream of data 103 (e.g. an audio and/or video data stream) to each of the clients 102.

(16) The present document is directed at providing an optimized trade-off between the allocation of (network) resources of the CDN 100 (notably of the resources of the server 101 and/or the resources of a transmission network between the server 101 and the one or more clients 102) and the resulting quality of experience (QoE) for the users of the clients 102. In this context, feedback channels 111, 112 may be provided to facilitate iterative metadata exchange between the server 101 and the clients 102, wherein the feedback channels 111, 112 are provided in parallel to the streaming channel 113 for the multimedia streaming process. The metadata exchange via the feedback channels 111, 112 may be used to facilitate global and/or overall optimization of the streaming process, and may be used, for instance, to reduce or to eliminate client competition for the finite (network) resources of the CDN 100. The metadata exchange process may generate dynamic side or control information for each client 102, wherein the side or control information may be used to adjust the local policy governing the streaming process at each client 102.

(17) Each client 102 may update and/or generate its client metadata 122 (to be send over the client feedback channel 112) based on the server metadata 121 received from the server 101 (over the server feedback channel 111). Furthermore, the client metadata 122 may be updated and/or generated based on a local client utility or cost function of the client 102. Subsequent to generating and/or updating the client metadata 122, the client 102 may transmit the (updated) client metadata 122 to the one or more servers 101 that the client 102 is connected to for streaming data, via the corresponding one or more client feedback channels 112.

(18) The server 101 may collect at least a subset of the client metadata 122 received from the clients 102 that are served by the server 101. Furthermore, the server 101 may generate and/or update server metadata 121 based on the received client metadata 122 and/or based on a local server utility or cost function. The generated and/or updated server metadata 121 may then be sent to at least a subset of the clients 102, via the one or more server feedback channels 111. This process of exchanging and updating metadata 121, 122 may be repeated iteratively and/or periodically. The updates of metadata 121, 122 may be transmitted in a synchronous or an asynchronous manner Each client 102 may be configured to update its request for new content from the server 101 based on the received server metadata 111 and/or based on its local utility or cost function. In particular, the request for new content may be performed in dependence of side or control information that has been established in the context of the iterative message passing process (subject to occurrence of a convergence event of the iterative message passing process).

(19) The exchange of metadata 121, 122 via feedback channels 111, 112 provides an algorithmic solution for a decentralized control scheme for a streaming scenario (e.g., for progressive streaming). The scheme described herein facilitates the decision of a client 102 to request content at a specific rate and/or at a specific quality level.

(20) In case of limited resources of the CDN 100 (e.g., due to a transmission bottleneck), the clients 102 are forced to compete for the limited resources. The client competition may result in an unfair resource allocation, or in instable QoE. These issues may be addressed by a centralized control scheme that collects requests from the clients 102, that analyzes the operation of the clients 102 and then provides the clients 102 with optimal resource allocation. However, if content distribution occurs at a large scale, a centralized solution is typically not feasible (in view of computational complexity and/or in view of dynamic changes within a CDN 100 and/or within the different clients 102). The (continuous and/or repeated) exchange of metadata 121, 122 between a server 101 and the clients 102 provides a robust and efficient resource allocation scheme for a CDN 100 that comprises servers and/or a high number and/or servers a high number of clients 102.

(21) The client utility functions which may be used by the clients 102 to generate the client metadata 122 may be individual and/or different for each client 102. The client utility function of a client 102 may be configured to capture and/or quantify the QoE of the client 102. The client utility functions of the different clients 102 may be designed such that the QoE can be compared among the different clients 102. In particular, the client utility functions may make use of a common criteria for measuring QoE. An example of such a client utility function (in the context of audio streaming) is the MUSHRA (MUltiple Stimuli with Hidden Reference and Anchor) score, as a function of bit-rate (wherein the total bit-rate is the limited resource). FIG. 4a shows example client cost functions 400 for different clients 102. The cost functions 400 indicate the MUSHRA loss as a function of the bit rate. FIG. 4b illustrates corresponding client utility functions 410, which indicate the utility 412 for a client 102 as a function of the bit-rate 411. The client cost function 400 may be considered to be the complement of the corresponding client utility function 410.

(22) The cost or utility functions 400, 410 for the clients 102 may depend on the content type that is streamed and/or rendered, on the codec that is used, on the playout or rendering scheme, on the listening conditions and/or on the priority of a client 102. Cost or utility functions 400, 410 may be provided e.g. for video and/or audio content. As such, a cost or utility function 400, 410 for a client 102 may indicate a level of QoE as a function of the bit rate 411 and/or of another resource. Differences in the value of utility functions 410 of different clients 102 may indicate that a particular change of the bit rate 411 and/or the resource may have a different impact on the level of QoE for the different clients 102. This is illustrated by the points 402, 403 in FIG. 4a. It can be seen that the increase in MUSHRA loss which is caused by a certain decrease in bit-rate 411 may be different for different cost functions 400, i.e. for different clients 102. The schemes outlined in the present document may be directed at maximizing the average level of QoE for the different clients 102 of a CDN 100, given a limited quantity of overall network resources.

(23) Hence, a decentralized control scheme for a massive streaming scenario is described, in order to improve the trade-off between allocation of the limited resources of a CDN 100 among the clients 102 of the CDN 100 and the resulting QoE for these clients 102. Such a technical problem may be viewed as a distributed optimization problem. To facilitate distributed optimization, a metadata exchange scheme may be used, wherein the metadata exchange between the one or more servers 101 and the one or more clients 102 occurs in parallel to the actual streaming processes towards the one or more clients 102. The metadata exchange scheme allows performing message passing which is a component of a distributed optimization scheme. In addition to the messages of the distributed optimization scheme, the metadata 121, 122 exchanged between the one or more servers 102 and the one or more clients 102 may include additional parameters that govern convergence speed and/or adaptivity of the optimization algorithm.

(24) In view of the fact that the client utility functions 410 of the one or more clients 102 are typically non-linear functions, linear programming cannot be used for solving the resource allocation problem. On the other hand, a distributed optimization scheme, such as the Alternating Direction Method of Multipliers scheme, may be used for determining an (optimal) solution of the resource allocation problem, based on message passing, i.e. based on the exchange of metadata 121, 122. It should be noted that the aspects outlined in the present document may also be applied to cross-CDN optimization (e.g., in case that network coding is used to implement simultaneous streaming of data 103 for a client 102 from multiple servers 101).

(25) The total resource (e.g. bit-rate) available within a CDN 100 may be r.sub.total. The total resource has to be shared among N client 102 n=1, . . . , N. The allocated quantity of the resource for each client n may be denoted as r.sub.n. Hence, the overall optimization problem to be solved is

(26) $\underset{\left(r_1,\mathrm{.Math.},r_N\right)}{\mathrm{minimize}}\underset{n=1}{\overset{N}{.Math.}}{d}_n\left(r_n\right)$$\mathrm{subject}\mathrm{to}\underset{n=1}{\overset{N}{.Math.}}{r}_n\le r_{\mathrm{total}},r_n\ge 0,n=1,\mathrm{.Math.},N$
wherein d.sub.n(r.sub.n) is the client cost function 400 of client n, e.g. a rate-distortion function such as d.sub.n(r.sub.n)=α.sub.ne.sup.−β.sup.n.sup.r.sup.n, with α.sub.n and β.sub.n being positive parameters that may be different for each client 102.

(27) It can be shown that the above optimization problem can be reformulated to provide
minimize Σ.sub.n=1.sup.Nd.sub.n(r.sub.n)+g(Σ.sub.n=1.sup.Nz.sub.n)
subject to r.sub.n=z.sub.n, n=1, . . . , N.
wherein g( ) is an indicator function given by

(28) $g\left(s\right)=\{\begin{array}{c}0\mathrm{if}s\le r_{\mathrm{total}},\\ \infty \mathrm{if}s>r_{\mathrm{total}}.\end{array}$
The objective of minimizing the sum of the client cost functions d.sub.n(r.sub.n) is separable into sub-problems that can be solved independently by each client 102 (using the respective client cost function). At a certain iteration k of the message passing process, a client n 102 may receive a message from the server 101 with server metadata 121, wherein the server metadata 121 comprises information regarding the allocated quantity of the resource r.sub.n.sup.(k) that has been allocated to the client n. In particular, the server metadata 121 may comprise values z.sub.n.sup.(k) and u.sub.n.sup.(k), which in combination are indicative of the allocated quantity of the resource r.sub.n.sup.(k). The client 102 may then solve the following optimization problem, in order to determine an updated request, i.e. an updated requested quantity of the resource r.sub.n.sup.(k+1),

(29) ${r_n^{\left(k+1\right)}=\underset{r}{\arg \min }(d_n\left(r\right)+\frac{\rho }{2}.Math.r-z_n^{\left(k\right)}+u_n^{\left(k\right)}.Math.}^2),$
wherein ρ is a tunable parameter. Hence, the client 102 may determine an updated resource request which takes into account the client cost function 400 of the particular client 102 and which takes into account the resource allocation provided by the server 101. The updated resource request r.sub.n.sup.(k+1) may then be provided within client metadata 122 to the server 101.

(30) The server 101 receives the resource requests r.sub.n.sup.(k+1) from the N clients 102 (wherein the resource requests of the different clients 102 depend on the client cost functions 400 of the different clients 102). Based on this information, the server 101 may update the resource allocation for the different clients 102.

(31) $z^{\left(k+1\right)}=\underset{z}{\arg \min }\left(g\left(\underset{n=1}{\overset{N}{.Math.}}{z}_n\right)+\frac{\rho }{2}\underset{n=1}{\overset{N}{.Math.}}{.Math.z_n-u_n^{\left(k\right)}-r_n^{\left(k+1\right)}.Math.}^2\right),u_n^{\left(k+1\right)}=u_n^{\left(k\right)}+r_n^{\left(k+1\right)}-z_n^{\left(k+1\right)}.$
The values z.sub.n.sup.(k+1) and u.sub.n.sup.(k+1) may then be sent as server metadata 121 to the clients 102 (in order to indicate the updated allocated quantity of the resource). This process may be repeated iteratively, in order to provide an optimized resource allocation for the N clients 102, such that the overall cost Σ.sub.n=1.sup.Nd.sub.n(r.sub.n) of the plurality of clients 102 is minimized, i.e. such that the average QoE for the clients 102 is maximized.

(32) It can be shown that the first equation of the optimization problem of the server 101 may be simplified to

(33) $z_n^{\left(k+1\right)}=a_n+\stackrel{\_}{z}-\frac{1}{N}\underset{n=1}{\overset{N}{.Math.}}{a}_n$
wherein z=r.sub.total/N, and a.sub.n=u.sub.n.sup.(k)+r.sub.n.sup.(k+1), thereby further reducing the computational complexity of the scheme.

(34) FIG. 2a shows a flow chart of a method 200 performed by a client 102. The client 102 receives 201 server metadata 121 from a server 101. Optionally, the client 102 may update 202 its local client cost function 400. The client cost function 400 may be minimized 203 based on the received server metadata 121 and updated client metadata 122 may be generated 204. This may be achieved by using the above mentioned formula for the updated resource request r.sub.n.sup.(k+1). The updated resource request r.sub.n.sup.(k+1) may then be transmitted 205 to the server 101. Subject to convergence of the message passing scheme for establishing a resource allocation, the content request for streaming data may be updated 206 based on the received server metadata 121, notably based on the allocated resource z.sub.n.sup.(k), u.sub.n.sup.(k) indicated within the server metadata 121. Furthermore, streaming data 103 may be requested from the server 101 in accordance to the allocated resource (step 207).

(35) Hence, a client 102 generates new client metadata 122 to be sent to the server 101 that is based on a local client cost function 400 and based on server metadata 121 received from the server 101. Furthermore, a client 102 comprises decision logic that is based on the received server metadata 121 and the newly generated client metadata 122 and that is used to trigger the actual request for content at a specific bitrate from the server 101 (e.g., upon observing convergence of the message passing process).

(36) Each client 102, upon convergence of the message passing process, will be provided with side information r* (which is also referred to herein as control information) representing an allocated resource (notably an allocated bit-rate) leading to fair resource allocation in the CDN 100. Each client 102 will generate a request for a specific quantity of the resource (notably a specific bit-rate) that is based on a local client utility function 410 representing the QoE (e.g., a function representing the quality of playout as a function of bitrate, a function promoting smooth playout, or a combination of these functions), by observing its buffer state and by using the fair rate allocation r* (i.e. by using the established control information). An example of such policy can be derived by using a renewal system model with two queues: the first queue represents the playout process, and the second queue represents the deviation of the bit-rate selected by the client 102 and the recommended rate r* provided by the server 101. The policy can be derived by minimizing the Lyapunov drift for the request with a penalty term representing the QoE-related client utility function 410. A further example of such a policy may be achieved by limiting the maximum amount of resources that can be requested by the client such that r* is not exceeded for the client. In particular, such constraint may be combined with a policy aiming at local optimization of QoE.

(37) FIG. 2b illustrates the processing 210 performed within a client 102 as part of a control policy for streaming data 103. The client 102 receives an indication 212 of a fair rate allocation (e.g. z.sub.n.sup.(k) and u.sub.n.sup.(k) subject to convergence) within the server metadata 121. Furthermore, the client 102 has access to a QoE function 211 (e.g. a client cost function 400 or a client utility function 410). In addition, the client 102 may have access to the state of its buffer 213 for buffering streaming data 103. Based on this information 212, 211, 213, an updated resource request 214 may be generated and may be provided to the server 101 within client metadata 122.

(38) FIGS. 3a and 3b illustrate methods 310, 320 performed by a server 101. The method 310 is directed at generating server metadata 121 for the different clients 102. The method 320 is directed at providing content (media) data 103 to the different clients 102. Client metadata 122 is received 311 at least from a subset of clients 102. This client metadata 122 is accumulated 312. Furthermore, a server utility function is computed 313 and new server metadata 121 is generated 314, e.g. using the equations for z.sub.n.sup.(k+1) and u.sub.n.sup.(k+1) given above. The updated server metadata 121 may then be sent to the clients 102. Regarding the streaming process, an updated content request may be received 321 from a client 102 (e.g. indicating an updated bit-rate 411). Content data 103 may then be sent 325 to the client 102, based on the updated content request.

(39) Hence, the server 101 collects all client metadata 122 (or a subset of metadata) from the clients 102 that are connected to the server 101 and solves an optimization problem based on its own utility function (e.g., representing the maximum allowed bitrate r.sub.total to be transmitted over the network 100, or considering the estimated bottleneck capacity to the clients 102). The solution of the optimization problem is used to generate new server metadata 121 that is transmitted to the clients 102 (or at least some of the clients 102). The method 310 is preferably designed in a way that the server optimization problem is computationally light. In addition, the server 101 provides access to the data 103 requested by the clients 102 (the streaming process operates in pull mode). In some embodiments, the service may operate on different machines or in different physical locations.

(40) FIG. 5a shows a streaming process comprising a single server 101 which provides streaming data 103 over streaming channels 113 to a plurality of clients 102. Each client 102 operates in a unicast setting. Each client 102 is characterized by its own client utility function 410. An example of such client utility function 410 in the context of streaming is a concave curve fitted to results of a MUSHRA test evaluating subjective performance of an audio codec as a function of the operating bit rate 411 (as illustrated in FIG. 4b). If the optimization is formulated as a minimization problem (as outlined above), the utility function 410 may be replaced by a corresponding cost or rate-distortion function d.sub.n(r.sub.n) 400, which is preferably convex. The rate-distortion or cost function 400 may be obtained by inverting the sign of the utility function 410 and by offsetting the utility function 410. Furthermore, the rate-distortion or cost functions 400 of the different clients 102 may be weighted and/or an offset may be applied to facilitate comparison among the different rate-distortion or cost functions 400.

(41) As outlined above and as shown in FIGS. 5b and 5c, server metadata 121 which is indicative of the allocated resource z.sub.n.sup.(k), u.sub.n.sup.(k) may be sent to the clients 102. On the other hand, updated resource request r.sub.n.sup.(k) may be sent as client metadata 122 from the clients 102 to the (single) server 101. By iterating this exchange of metadata 121, 122, a converged resource allocation for the different clients 102 may be determined. It should be noted that each client 102 may be configured to detect whether the scheme has converged by evaluating convergence of the residual term ∥r−z.sub.n.sup.(k)+u.sub.n.sup.(k)∥.sup.2 when determining the updated resource request r.sub.n.sup.(k). Alternatively or in addition, the convergence may be evaluated by observing convergence of all or some metadata variables exchanged in the message passing process (e.g. r.sub.n.sup.(k) and r.sub.n.sup.(k+1) may be compared). Alternatively or in addition, each client may assume convergence upon reaching a fixed number of iterations. Alternatively or in addition, the fact of convergence may be signaled from the server 101 during the process of exchanging the metadata 121, 122.

(42) FIG. 6a shows a CDN 100 having a bottleneck 602 with a limited throughput between two transmission nodes 601. The limited throughput, i.e. a limited value for r.sub.total, may be distributed among different clients 102. Alternatively or in addition, the number N of clients 102 that may be served by the server 101 may be adjusted, notably reduced. As shown in FIG. 6b, the limited throughput of a bottleneck 602 may also be caused by competing traffic between a source 611 and a sink 612.

(43) FIG. 7a shows a streaming scenario with a plurality of CDNs 100, 700. Each CDN 100 comprises at least one server 101, 701. One or more clients 102 may be part of a plurality of CDNs 100, 700 and may stream data 103 from a plurality of servers 101, 701 (as illustrated in FIG. 7b). In such a case, a client 102 may receive server metadata 121 from a plurality of servers 100, 700. Furthermore, a client 102 may send client metadata 122 to a plurality of servers 100, 700 (as illustrated in FIG. 7c).

(44) In the following, a cooperative resource allocation for the multi-server streaming process shown in FIG. 7a is described. It is assumed that a client 102 can stream data 103 from M different servers 101, with M>1. r.sub.n is an M-dimensional vector which indicates the M allocated resource for streaming the data 103 provided by the M servers 101, respectively. 1.sup.T is an M-dimensional vector with all ones. Then the cost or rate-distortion function 400 of a client 102 may be written as
d.sub.n(r.sub.n)=α.sub.nexp(−β.sub.n1.sup.Tr.sub.n)
The overall optimization problem for all N clients 102 and for all M servers 101 may be written (in an analogous manner as outlined above), as
minimize Σ.sub.n=1.sup.Nd.sub.n(r.sub.n)+Σ.sub.m=1.sup.Mg.sub.m(Σ.sub.n=1.sup.N[z.sub.n].sub.m)
subject to r.sub.n=z.sub.n.
wherein [z.sub.n].sub.m is the m.sup.th entry (for the m.sup.th server 101) of the M-dimensional resource-allocation vector z.sub.n for the n.sup.th client 102. The indication function g.sub.m( ) for the m.sup.th server 101 may be defined as

(45) $g_m\left(s\right)=\{\begin{array}{c}0\mathrm{if}s\le r_{\mathrm{total}}^{\left(m\right)},\\ \infty \mathrm{if}s>r_{\mathrm{total}}^{\left(m\right)},\end{array}$
wherein r.sub.total.sup.(m) is the total bitrate available for the m.sup.th server.

(46) It can be shown that the above mentioned optimization problem may be solved using message passing between the clients 102 and the servers 101. Each client 102 may receive server metadata 121 from the servers 101, 701 m=1, . . . , M, wherein the server metadata 121 indicates the allocated quantity of the resource [z.sub.n].sub.m that has been allocated by the m.sup.th server 101, 701 to the n.sup.th client 102. Furthermore, the auxiliary variable [u.sub.m].sub.n may be indicated (as part of the allocated quantity of the resource). The client 102 may receive this data from all servers 101, 701 and based on this, the client 102 may generate updated resource requests for the M servers 101, 701.

(47) Overall, N×M resource requests may be generated in case of N clients 102 and M servers 101, 701. These may be summarized within a matrix R with dimension N×M. The resource request of the n.sup.th client 102 towards the m.sup.th server 101, 701 may be written as the scalar [R].sub.n.sup.m. The complete set of resource requests of the n.sup.th client 102 for all M servers 101, 701 may be written as the M-dimensional vector r.sub.n=[R].sub.n. In a similar manner, the resource allocation of the M servers 101, 701 towards the N clients 102 may be written as an N×M dimensional Matrix Z, with [Z].sub.n.sup.m being the resource allocation of the m.sup.th server 101, 701 for the n.sup.th client 102, and with [Z].sup.m being an N-dimensional vector comprising the resource allocation of the m.sup.th server 101, 701 for the N clients 102. u.sub.m may be an N-dimensional vector comprising the scalar auxiliary variables [u.sub.m].sub.n of the m.sup.th server 101, 701 for the N clients 102. Furthermore, a resource constraint function G.sub.m(z) may be defined for the m.sup.th server 101, 701, as

(48) $G_m\left(z\right)=g_m\left(\underset{n=1}{\overset{N}{.Math.}}{z}_n\right).$
Using the above mentioned notation, the optimization problem to be solved by the n.sup.th client 102 in the k.sup.th iteration may be formulated as

(49) ${\left[R^{\left(k+1\right)}\right]}_n=\underset{{\left[R\right]}_n}{\arg \min }\left(d_n\left({\left[R\right]}_n\right)+\underset{m=1}{\overset{M}{.Math.}}\frac{{\rho }_m}{2}{.Math.{\left[R\right]}_n^m-{\left[Z^{\left(k\right)}\right]}_n^m+{\left[u_m^{\left(k\right)}\right]}_n.Math.}_2^2\right)$
wherein ρ.sub.m is a design parameter. The updated resource requests [R.sup.(k+1)].sub.n.sup.m may be sent within client metadata 122 from the n.sup.th client 102 to the m.sup.th server 101, 701.

(50) The optimization problem to be solved by the m.sup.th server 101, 701 in the k.sup.th iteration may be formulated as

(51) 0${\left[Z^{\left(k+1\right)}\right]}^m=\underset{{\left[Z\right]}^m}{\arg \min }\left(G_m\left({\left[Z\right]}^m\right)+\frac{{\rho }_m}{2}{.Math.{\left[R\right]}_n^m-{\left[Z^{\left(k\right)}\right]}^m+u_m^{\left(k\right)}.Math.}_2^2\right)$
with the auxiliary variable being updated according to
u.sub.m.sup.(k+1)=u.sub.m.sup.(k)+[R.sup.(k+1)].sup.m−[Z.sup.(k+1)].sup.m
The updated resource allocation [Z.sup.(k+1)].sub.n.sup.m as well as the updated auxiliary variable [u.sub.m.sup.(k+1)].sub.n may be sent within server metadata 121 from the m.sup.th server 101, 701 to the n.sup.th client 102.

(52) The above distributed optimization scheme may be iterated until a stop criterium is met (i.e. a convergence occurred). After convergence, the determined resource allocations may be used by each client 102 to make content requests to the different servers 101, 701.

(53) Hence, performance (e.g. QoE) optimization may be performed across different CDNs 100, 700, wherein a CDN 100, 700 may be viewed as set of clients 102 streaming content 103 from a particular server 101, 701 and wherein each CDN 100, 700 may comprise a single server 101, 701. A (notably each) client 102 may be configured to participate in one or more CDNs 100, 700 (as illustrated in FIG. 7a).

(54) Each client 102 may be characterized by a known client function 400, 410 describing the performance or utility 412 of the client 102 as a function of the assigned rate 411. One example of such a function 400, 410 is a rate-distortion function (for example, in the context of an audio codec such a function may map the rate to e.g. the MUSHRA performance). The performance function (notably the client utility function) 400, 410 is typically client-specific. Furthermore, the performance function 400, 410 may change over time depending on the content type, the playback time and/or, for example, the listening conditions. The different CDNs 100, 700 are typically operated in an uncoordinated manner. Hence, there may be no (explicit) communication taking place between the servers 101, 701 of the different CDNs 100, 700. Furthermore, the clients 102 may not be communicating with one another.

(55) The goal of the overall optimization scheme may be to provide the best possible average experience for all clients 102, subject to: one or more server and/or resource constraints (e.g., the average rate per client may be constrained in each CDN 100, 700); and/or channel capacity constraints specific to each client 102.

(56) Such an optimization scheme may be formulated as a sharing problem. From the point of view of a client 102, the problem at hand is to find the optimal way of using the available network resources. On the other hand, the servers 101 will facilitate cooperation of the clients 102, thereby enabling an equilibrium to be achieved. The optimization problem can be solved by means of message passing in a distributed setting. The overall optimization problem may be subdivided into partial problems that can be solved by clients 102 in an independent manner. In particular, an iterative solution that comprises exchange of messages between servers 101, 701 and clients 102 can be provided, as outlined above.

(57) As illustrated in FIG. 7c, each server 101, 701 sends a message with individual server metadata 121 to each client 102 that the respective server 101, 701 is connected to. The server metadata 121 is specific to each client 102. The derivation of the server metadata 121 is a consequence of the particular distributed optimization method, e.g. as the one described above. This optimization method may be computationally light and may scale efficiently with the number N of connected clients 102. A client 102 provides an update to a server 101, 701 that is derived based on its own objective (notably based on its client utility function 410) and using the message received from the server 101, 701.

(58) In practice the granularity of the resource (e.g. the bit-rate) and/or the quality of different available versions of content may be limited. This issue may be addressed by quantizing the determined resources (notably the resource requests and/or the allocated resources) in accordance to the available granularity. Hence, the optimization scheme may be solved for the continuous case, and the determined solution may be quantized. In particular, a client 102 may be adapted to determine a (continuous) resource request r.sub.n as outlined in the present document. The resource request r.sub.n may then be projected to one of the discrete quantities of the resource s.sub.n which are available. In particular, the discrete resource quantity s.sub.n which is closest to the determined (continuous) resource request r.sub.n may be selected and may be provided to the server 101. On the other hand, the operations at the server 101, 701 may be performed in a continuous manner.

(59) As outlined above, a client 102 may request content from a server 101 based on the (converged) side or control information exchanged between the client 102 and the server 101, notably based on r*, which is the converged allocated quantity of the resource, e.g. z.sub.n.sup.(k) and/or u.sub.n.sup.(k) after convergence. This side or control information may be used to improve the client control policy, i.e. the policy which the client 102 uses to manage the streaming, the buffering and the rendering of media data 103.

(60) In a typical HTTP-based adaptive streaming scenario, there are several versions (or quality levels) of media content, which are encoded at different bit-rates and which exhibit different quality. The available bandwidth of the data connection from the server 101 to the client 102 is typically time variable and it is up to the client's control policy to select an appropriate quality version or quality level of the content. The client's control policy may attempt to maximize its client utility function 410 (e.g. maximize the quality), subject to the constraint that no buffer underrun is allowed. Given the available bandwidth of the data connection and a constant playout rate, there is typically a trade-off between the playout quality and the average fullness of the buffer. This is due to the fact that downloading a higher quality version of the content would require more downloading time (at an unchanged bandwidth of the data connection). Furthermore, one or more other types of constraints may be taken into account within the client's control policy. For example, it may not be desirable to toggle between different quality versions of content, as this would result in an instable playout quality.

(61) The client control policy may be configured to estimate the available throughput of a network, by means of an explicit measurement of the download speed and/or by observing the state of the buffer of the client 102. By way of example, if it is observed that the buffer is filling up, then this is an indication that the requested data-rate is too high. On the other hand, if it is observed that the buffer is getting empty, then this may indicate that the requested rate is too low.

(62) A streaming process may be performed on a per segment basis, wherein the streamed content is split into relatively short segments. The control policy of a client 102 may be configured to adapt the quality version or quality level of content to be streamed for each of the segments.

(63) An example of the operation of the client control policy is shown in FIG. 8a. In particular, FIG. 8a shows the fullness level 801 of the playout buffer as a function of time. Furthermore, FIG. 8a illustrates the observed throughput 802 and the selected quality level 803 of the downloaded segments. It can be seen that subsequent to a transient phase, the control policy is directed at matching the available throughput 802 by selecting quality levels 803 corresponding to bit-rates that are in line with the available throughput 802. The transient phase is relatively long. Furthermore, the buffer fullness level 801 is relatively high. In addition, the selection of a quality level 803 is quite erratic.

(64) The side or control information r* may be used to improve performance of a control policy of a client 102. As a matter of fact, the side information provides an indication to the client 102 of the available or allocated rate for the client 102. It may be assumed that all the clients 102 implement the same control policy and are supplied with their respective r* side information. An example of the effect achieved by supplying r* is shown in FIG. 8b. It can be seen that the playout buffer fullness level 801 is lower than in the case of FIG. 8a. In particular, the buffer fullness 801 increases at a much slower rate than in the case of FIG. 8a. Nevertheless, there is no buffer underrun, such that a smooth playout can be ensured. Furthermore, FIG. 8b shows the quality level 803 of the downloaded segments and the observed throughput 802. It can be seen that the transient phase has been shortened. This is due to the fact that the knowledge of the allocated rate r* enables the client 102 to apply a less conservative policy (because the client 102 may assume that a rebuffering event is unlikely, in view of that fact that the value of r* should correspond to the observed throughput 802). Furthermore, the playout policy may result in a more stable selection of the quality level 803, since instances with an overly high rate may be avoided, and since the policy may accept an increased risk in the event that the observed throughput 802 decreases.

(65) If the side information r* is temporarily not available the client policy may operate without it by performing local optimization of QoE subject to a buffer underrun prevention penalty. However, once the side information r* is established, the client control policy may be conditioned based on the side information. The established side information r* may be deemed obsolete after some predefined time interval and the client may revert to a local optimization strategy. The side information r* may be established periodically, notably with a frequency which ensures that the updates of the side information r* are provided with sufficient time resolution.

(66) In other words, the message passing process which is described in the present document may be repeated with a certain frequency f=1/T, with f being 0.01 Hz, 0.05 Hz, 0.1 Hz, 1 Hz or more. Hence, updated side information r* may be provided with the frequency f. A client 102 or client agent may assume that side information which has been established at a particular time instant is valid for a validity period (which may be equal to or greater than T). If no updated side information is received at the end of the validity period, the client 102 or client agent may modify its client control policy by switching to a local optimization of the QoE (e.g. without taking into account an allocated quantity of the resource) for requesting content from the one or more servers 101. On the other hand, the updated side information may be taken into account, if it is received within the validity period and/or as soon as it is received. By doing this, a stable operation of a client 102 may be achieved.

(67) It should be noted that the schemes which are described in the present document may be integrated with MPEG DASH, notably within the interface of server and network assisted DASH (SAND) by attaching the dynamic metadata to the messages being sent (see ISO/IEC JTC 1/SC 29).

(68) Hence, in the present document a method for establishing side or control information for client streaming control policies is described. The side information is established by using an iterative message passing process, wherein the message passing process occurs between server side nodes and client nodes. The process generates convergence events, when the side information is established. The side information may be used for adaptation of client control policies.

(69) In the present document a method which is based on an Alternating Direction Method of Multipliers (ADMM) scheme is described for solving the overall resource allocation problem. It should be noted that other distributed optimization algorithms can be used for solving the overall resource allocation problem. In general terms, the overall resource allocation problem may be solved by decomposing the global optimization problem into partial optimization problems (e.g., optimization problems that can be solved on the clients 102 and on the server 101, respectively); performing an iterative message passing procedure; and generating convergence events, when the side information is established.

(70) Once the side information is established, it may be used to adapt the client control policy. The client control policy may, for example, govern the process of requesting content at a specific bitrate.

(71) The convergence event may be generated e.g. in the following ways: the convergence event may be determined by each client 102 by observation of the convergence of the residual term in the client's optimization problem; the convergence event may be achieved by using a fixed number of message passing iterations; and/or the convergence event may be indicated by the server side node by tagging the outgoing server messages and therefore triggering the side information update event in the clients.

(72) A client may identify the convergence event when its available side information is deemed to be obsolete, by observing: a lack of incoming messages from the server side within some predefined time window; a lack of convergence of its residual; a predefined time interval measured on the client side; and/or a received tagged server side message.

(73) It should be noted that the server side metadata exchange agent does not need to be co-located with the server 101 which stores the content. The distributed optimization scheme may involve an agent that operates on the server side and that participates in the message exchange process with all the connected clients 102. In the iterative optimization scheme that is described in the present document, the agent may be configured to collect the resource requests from the clients 102 and to determine the resource allocations. Even though the agent is typically located on the server side, the actual network node does not need to be co-located with the server 101 that stores and provides the content. For example, the node or agent participating in the metadata exchange may be located at a deeper or higher level of the network 100, 700.

(74) It should be noted that the schemes described herein typically assume servers 101 operating in a pull mode, where a client 102 requests the content (as opposed to the push mode, where the server 101 actively pushes data to the clients 102).

(75) In view of a stable and/or fast convergence, the updates of the iterative message passing procedure are preferably performed in a synchronous manner In particular, the server 101 may be configured to issue an update (i.e. server metadata 121) to the connected clients 102 only after receiving all messages (i.e. client metadata 122) from the clients 102. On the other hand, partial barrier schemes may be applied to the processing of the server 101, in order to perform asynchronous operation.

(76) FIG. 9a shows a flow chart of an example method 900 for establishing control information for a control policy of a client 102 for streaming data 103, notably media, such as video and/or audio data, from at least one server 101, 701. The control information may be used by the client 102 to request data 103 from the at least one server 101, 701. The client 102 may e.g. comprise a smartphone, a computer, a TV set, etc.

(77) The method 900 comprises performing 901 a message passing process between a server agent of the server 101, 701 and a client agent of the client 102, in order to iteratively establish control information. The server agent may be co-located with or separate from the server 101, 701. In a similar manner the client agent may be co-located with or separate from the client 102. In the context of the message passing process, the server agent may generate server metadata 121 based on client metadata 122 received from the client agent. Furthermore, the client agent may generate client metadata 122 based on the server metadata 121 received from the server agent. This iterative exchange of messages and/or metadata may be repeated to establish control information for the control policy that is to be used by the client 102 for streaming data 103 from the server 101, 701.

(78) Furthermore, the method 900 comprises generating 902 a convergence event for the message passing process to indicate that the control information has been established. As a result of this, the client 102 is enabled to request data 103 from the server 101, 701 based on iteratively established control information (which is also referred to herein as side information). By doing this, optimized content distribution may be performed within a content delivery network 100, 700.

(79) FIG. 9b shows a flow chart of an example method 910 for establishing control information for a control policy of at least one client 102 for streaming data 103 from a server 101, 701. The method 910 may be performed by the server agent of the server 101, 701, e.g. in the context of method 900.

(80) The method 910 comprises receiving 911 client metadata 122, wherein the client metadata 122 may be received from a client agent of the client 102. The client metadata 122 may be indicative of a requested quantity of a resource 411 (e.g. of a requested bit-rate) which is requested by the at least one client 102 for streaming data 103 from the server 101, 701. In particular, different sets of client metadata 122 may be received 911 from a plurality of client agents for a plurality of clients 102, wherein the plurality of clients 102 may be competing for a limited total quantity of the resource 411.

(81) Furthermore, the method 910 comprises determining 912 server metadata 121 based on the received client metadata 122 (from the one or more client agents). The server metadata 121 may be indicative of an allocated quantity of the resource 411 allocated to the at least one client 102 for streaming data 103 from the server 101, 701. In particular, different sets of server metadata 121 may be determined 912 for the plurality of clients 102 (notably one set of server metadata 121 for each client 102).

(82) In addition, the method 910 comprises sending 913 the server metadata 121, the server metadata 121 is typically sent to the client agent of a client 102. In particular, individual server metadata 121 may be sent to each of the plurality of client agents for the plurality of clients 102.

(83) The method 910 comprises repeating 914 the receiving 911, the determining 912 and the sending 913 steps until occurrence of a convergence event. The repeating 914 may be performed in the context of a message passing process between the server agent and the one or more client agents. The convergence event may indicate that control information for the control policy of the at least one client 102 for streaming data 103 from the server 101, 701 has been established based on the iterative receiving 911 of client metadata 122 and sending 913 of server metadata 121. The established control information may then be used by the client 102 for requesting data 103 from the server 101, 701. By performing method 910, optimized content distribution may be performed within a content delivery network 100, 700.

(84) FIG. 9c shows a flow chart of an example method 920 for establishing control information for a control policy of a client 102 for streaming data 103 from at least one server 101, 701. The method 920 may be performed by a client agent of the client 102.

(85) The method 920 comprises receiving 921 server metadata 121. The server metadata 121 may be received by the server agent of the at least one server 101, 701. The client 102 may be configured to stream data 103 for an overall media content that is to be rendered by the client 102 from a plurality of different servers 101, 701. In such a case, server metadata 121 may be received from each one of the plurality of servers 101, 701. The server metadata 121 may be indicative of an allocated quantity of a resource 411 allocated to the client 102 for streaming data 103 from the respective server 101, 701.

(86) Furthermore, the method 920 comprises determining 922 client metadata 122 based on the server metadata 121 (from the one or more servers 101, 701 or server agents). The client metadata 122 may be indicative of a requested quantity of the resource 411 requested by the client 102 for streaming data 103 from the at least one server 101, 701. A set of client metadata 122 may be generated for each one of the plurality of servers 101, 701.

(87) In addition, the method 920 comprises sending 923 the client metadata 122 (to the one or more servers 101, 701 or server agents).

(88) The method 920 repeats 924 the receiving 921, the determining 922 and the sending 923 steps until occurrence of a convergence event (e.g. in the context of a message passing process). The convergence event may indicate that control information for the control policy of the client 102 for streaming data 103 from the at least one server 101, 701 has been established based on the iterative receiving 921 of server metadata 121 and sending 923 of client metadata 122. The established control information may then be used by the client 102 for requesting data 103 from the one or more servers 101, 701. By performing method 920, optimized content distribution may be performed within a content delivery network 100, 700.

(89) Various aspects of the present invention may be appreciated from the following enumerated example embodiments (EEs): EE 1) A method (900) for establishing control information for a control policy of a client (102) for streaming data (103) from at least one server (101, 701); wherein the method (900) comprises, performing (901) a message passing process between a server agent of the server (101, 701) and a client agent of the client (102), in order to iteratively establish control information; and generating (902) a convergence event for the message passing process to indicate that the control information has been established. EE 2) The method (900) of EE 1, wherein performing (901) the message passing process comprises, within a given iteration, sending server metadata (121) from the server agent to the client agent; wherein the server metadata (121) at the given iteration depends on client metadata (122) sent from the client agent to the server agent at a previous iteration; and sending client metadata (122) from the client agent to the server agent; wherein the client metadata (122) at the given iteration depends on the server metadata (121) sent from the server agent to the client agent at the given iteration. EE 3) The method (900) of EE 2, wherein the method (900) comprises determining client metadata (122) based on a client utility function (410); and the client utility function (410) indicates a utility (412) for the client (102) of the data (103) received by the client (102), as a function of the quantity of a resource (411) that has been allocated to the client (102) for streaming data (103). EE 4) The method (900) of EE 3, wherein the client utility function (410) is indicative of and/or dependent on a perceptual quality of streamed media data (103) rendered by the client (102); and/or indicative of and/or dependent on a signal-to-noise ratio of streamed data (103) received and/or rendered by the client (102); and/or dependent on a rendering mode of the client (102); and/or dependent on a rendering environment of the client (102); and/or dependent on a type of the client (102); and/or time-variant. EE 5) The method (900) of any of EEs 2 to 4, wherein the method (900) comprises determining a requested quantity of the resource (411), requested by the client (102), based on the client utility function (400, 410); and the client metadata (122) is indicative of a requested quantity of the resource (411). EE 6) The method (900) of any of EEs 2 to 5, wherein the server metadata (121) is indicative of an allocated quantity of the resource (411) which is allocated to the client (102) for streaming data (103); and the method (900) comprises determining a requested quantity of the resource (411), requested by the client (102) in dependence of the allocated quantity of the resource (411). EE 7) The method (900) of EE 6 referring back to EE 5, wherein the requested quantity of the resource (411) is determined based on, notably by reducing or minimizing, a cost function which comprises a first term indicative of a deviation of the requested quantity of the resource (411) from the allocated quantity of the resource (411); and a second term comprising a complement of the client utility function (410). EE 8) The method (900) of EE 7, wherein the cost function comprises a weighted sum of the first term and the second term; and/or the first term is dependent on an absolute or a squared deviation of the requested quantity of the resource (411) from the allocated quantity of the resource (411). EE 9) The method (900) of EE 2 to 8, wherein the client metadata (122) is indicative of a requested quantity of the resource (411), requested by the client (102); and the allocated quantity of the resource (411) is determined based on the requested quantity of the resource (411). EE 10) The method (900) of any of EEs 2 to 9, wherein the method (900) comprises determining the server metadata (121) in dependency of a total quantity of a resource (411) to be allocated to a plurality of clients (102) for streaming data (103). EE 11) The method (900) of EE 10, wherein the client (102) is a first client (102) of the plurality of clients (102); the method (900) comprises determining an allocated quantity of the resource (411), which is allocated to the first client (102) for streaming data (103), based on the total quantity of the resource (411); and the server metadata (121) is indicative of the allocated quantity of the resource (411) which is allocated to the first client (102) for streaming data (103). EE 12) The method (900) of EE 11, wherein the method (900) comprises, receiving client metadata (122) from the plurality of clients (102) competing for the total quantity of the resource (411); and the allocated quantity of the resource (411) for the first client (102) is determined based on the requested quantity of the resource (411) from each of the plurality of clients (102). EE 13) The method (900) of any previous EEs, wherein the control information is indicative of or comprises a quantity of a resource (411) that has been allocated to the client (102) for streaming data (103). EE 14) The method (900) of EE 13, wherein the resource (411) comprises one or more of, a bit-rate for streaming data (103); and/or a processing capacity of the server (101) for providing data (103); and/or a bandwidth of a transmission network (601) between the server (101) and the client (102). EE 15) The method (900) of any previous EEs, wherein generating (902) the convergence event comprises, determining that a pre-determined maximum number of iterations of the message passing process has been reached; and/or determining that a change of the control information between two successive iterations of the message passing process is equal to or smaller than a pre-determined change-threshold; and/or determining that the client agent and/or the server agent have sent an indication for terminating the message passing process. EE 16) The method (900) of any previous EEs, wherein the method (900) comprises, generating a request for data (103) based on the established control information; and/or managing a buffer of the client (103) for buffering data (103) based on the established control information; and/or selecting a quality level (803) out of a plurality of different quality levels (803) of content to be streamed. EE 17) The method (900) of any previous EEs, wherein the method (900) comprises performing a pairwise message passing process between the server agent of the server (101, 701) and client agents of a plurality of clients (102), in order to iteratively establish control information for each of the plurality of clients (102); and the plurality of clients (102) compete for a total quantity of a resource (411) available for streaming data (103) from the server (102). EE 18) The method (900) of any previous EEs, wherein the method (900) comprises performing a pairwise message passing process between server agents of a plurality of servers (101, 701) and the client agent of the client (102), in order to iteratively establish control information for control policies of the client (102) for streaming data (103) from each of the plurality of servers (101, 701); and streaming different fractions of an overall media stream from the different servers (101, 701) based on the established control information for the different servers (101, 701), respectively. EE 19) A method (910) for establishing control information for a control policy of at least one client (102) for streaming data (103) from a server (101, 701); wherein the method (910) comprises, receiving (911) client metadata (122); wherein the client metadata (122) is indicative of a requested quantity of a resource (411) requested by the at least one client (102) for streaming data (103) from the server (101, 701); determining (912) server metadata (121) based on the received client metadata (122); wherein the server metadata (121) is indicative of an allocated quantity of the resource (411) allocated to the at least one client (102) for streaming data (103) from the server (101, 701); sending (913) the server metadata (121); and repeating (914) the receiving (911), determining (912) and sending (913) steps until occurrence of a convergence event; wherein the convergence event indicates that control information for the control policy of the at least one client (102) for streaming data (103) from the server (101, 701) has been established based on the iterative receiving (911) of client metadata (122) and sending (913) of server metadata (121). EE 20) A method (920) for establishing control information for a control policy of a client (102) for streaming data (103) from at least one server (101, 701); wherein the method (920) comprises, receiving (921) server metadata (121); wherein the server metadata (121) is indicative of an allocated quantity of a resource (411) allocated to the client (102) for streaming data (103) from the at least one server (101, 701); determining (922) client metadata (122) based on the server metadata (121); wherein the client metadata (122) is indicative of a requested quantity of the resource (411) requested by the client (102) for streaming data (103) from the at least one server (101, 701); sending (923) the client metadata (122); and repeating (924) the receiving (921), determining (922) and sending (923) steps until occurrence of a convergence event; wherein the convergence event indicates that control information for the control policy of the client (102) for streaming data (103) from the at least one server (101, 701) has been established based on the iterative receiving (921) of server metadata (121) and sending (923) of client metadata (122). EE 21) The method (920) of EE 20, wherein the method (920) comprises repeatedly determining updated control information using the receiving, determining, sending and repeating steps. EE 22) The method (920) of any of EEs 20 to 21, wherein the control information is established at a first time instant; the control information exhibits a validity period starting from the first time instant; the method (920) comprises, determining the control policy for streaming data (103) based on the control information during the validity period of the control information; and the method (920) comprises, applying a control policy for streaming data (103) which is independent of the control information, subsequent to the validity period of the control information. EE 23) A system (100, 700) for delivering content; wherein the system (100, 700) comprises at least one server (101, 701) configured to provide data (103) for streaming content to one or more clients (102); at least one client (102) configured to request data (103) for streaming content from the at least one server (101, 701); a server agent for the at least one server (101, 701) and a client agent for the at least one client (102); wherein the server agent and the client agent are configured to perform a message passing process between the server agent and the client agent, in order to iteratively establish control information for a control policy of the at least one client (102) for streaming data (103) from the at least one server (101, 701); and generate a convergence event for the message passing process to indicate that the control information has been established. EE 24) A server agent for a server (101, 701) of a content delivery network (100, 700); wherein the server agent is configured to receive client metadata (122); wherein the client metadata (122) is indicative of a requested quantity of a resource (411) requested by a client (102) for streaming data (103) from the server (101, 701); determine server metadata (121) based on the received client metadata (122); wherein the server metadata (121) is indicative of an allocated quantity of the resource (411) allocated to the client (102) for streaming data (103) from the server (101, 701); send the server metadata (121); and repeat receiving, determining and sending until occurrence of a convergence event; wherein the convergence event indicates that control information for a control policy of the client (102) for streaming data (103) from the server (101, 701) has been established based on the iterative receiving of client metadata (122) and sending of server metadata (121). EE 25) A client agent for a client (102) of a content delivery network (100, 700); wherein the client agent is configured to receive server metadata (121); wherein the server metadata (121) is indicative of an allocated quantity of a resource (411) allocated to the client (102) for streaming data (103) from a server (101, 701); determine client metadata (122) based on the server metadata (121); wherein the client metadata (122) is indicative of a requested quantity of the resource (411) requested by the client (102) for streaming data (103) from the server (101, 701); send the client metadata (122); and repeat receiving, determining and sending until occurrence of a convergence event; wherein the convergence event indicates that control information for a control policy of the client (102) for streaming data (103) from the server (101, 701) has been established based on the iterative receiving of server metadata (121) and sending of client metadata (122).

(90) The methods and systems described in the present document may be implemented as software, firmware and/or hardware. Certain components may e.g. be implemented as software running on a digital signal processor or microprocessor. Other components may e.g. be implemented as hardware and/or as application specific integrated circuits. The signals encountered in the described methods and systems may be stored on media such as random access memory or optical storage media. They may be transferred via networks, such as radio networks, satellite networks, wireless networks or wireline networks, e.g. the Internet. Typical devices making use of the methods and systems described in the present document are portable electronic devices or other consumer equipment which are used to store and/or render audio signals.