DETERMINING P2P NETWORK PERFORMANCE

A device and a method performed by the device for determining performance of a peer-to-peer (P2P) network. Performance of a P2P network including a plurality of peer devices may be determined by initiating distribution of content to at least one of the plurality of peer devices in the P2P network, the distribution of content being specified by at least one distribution parameter, acquiring, from the at least one peer device, at least one metric associated with the content received by the at least one peer device, and determining the performance of the P2P network based on the acquired at least one metric.

This application claims priority to and the benefit of Swedish Application 1550324-6, filed on Mar. 18, 2015, which is incorporated herein by reference.

TECHNICAL FIELD

The invention relates to a device and a method performed by the device for determining performance of a peer-to-peer network. The invention further relates to a computer program performing the method according to the present invention, and a computer program product comprising computer readable medium having the computer program embodied therein.

BACKGROUND

In state of the art peer-to-peer (P2P) content distribution systems, evaluation of system performance is carried out only after an actual content distribution event has taken place. Hence, evaluating and refining the end user experience would require that a significant number of end users actively participate in a number of content distribution events, which is often not feasible. Typical user behaviour is such that after having had a less satisfactory experience of a P2P content distribution event, the user is less likely to want to take part in future events. If a system operator collects data from a small sample of target users, it may be hard to draw general conclusions on system performance.

An example of such a situation may arise in the context of live streaming of a popular event for mass consumption (e.g. a popular sports event). In such a scenario, the end users may be subject to a variety of constraining factors that affects their individual experience and overall system performance. Examples of such factors include upload and download bandwidth capabilities, different types of connectivity constraints such as Network Address Translation (NAT) issues, different video rendering capabilities due to e.g. processor performance and load, etc. Additionally, constraints may exist in the physical network, such as P2P connectivity constraints, minimum P2P delay, maximal bandwidth on a P2P link, network congestion, packet loss, etc. All of these static and dynamic factors, taken alone or in combination, may have a very dramatic effect on the performance of the P2P system. Typically, most sophisticated P2P systems have a number of parameters that may be optimally tuned for a given set of performance-constraining factors.

SUMMARY

An object is to solve, or at least mitigate, this problem in the art and to provide an improved method of evaluating performance of a P2P network.

This object is attained in a first aspect of the present invention by a method of determining performance of a P2P network comprising a plurality of peer devices. The method comprises initiating distribution of content to at least one of the plurality of peer devices in the P2P network, the distribution of content being specified by at least one distribution parameter. The method further comprises acquiring, from the at least one peer device, at least one metric associated with the content received by the at least one peer device, and determining the performance of the P2P network based on the acquired at least one metric.

This object is attained in a second aspect of the present invention by a device configured to determine performance of a P2P network comprising a plurality of peer devices, the device comprising a processing unit being arranged to execute instructions, whereby the device is operative to initiate distribution of content to at least one of the plurality of peer devices in the P2P network, the distribution of content being specified by at least one distribution parameter. The device is further operative to acquire, from the at least one peer device, at least one metric associated with the content received by the at least one peer device, and to determine the performance of the P2P network based on the acquired at least one metric.

Thus, an evaluation process is advantageously provided for evaluating, and optionally for subsequently tuning, parameters of the P2P content distribution network in order to increase the network performance. In the P2P content distribution network, being for instance a live streaming P2P network or a video on demand (VOD) P2P network, a device according to the invention referred to as a Remote Testing (RT) server initiates distribution of content to one or more of the peer devices in the P2P network, by instructing the peer device(s) to download the content from a content distribution source such as e.g. a single streaming source or a content distribution network (CDN), or one or more neighbouring peer devices. Typically, to able to perform an adequate evaluation of the P2P network performance, data of a great number of peers is collected and evaluated.

The RT server initiates the distribution of the content from a content distribution source to each peer based on one or more distribution parameters including e.g. quality of the distributed content (particularly important in case of distributed video or audio data and commonly expressed in terms of bit rates), a download locality parameter specifying likelihood that a given peer will download the content from a proximate neighbouring peer, maximum allowable hop count of a peer from the content distribution source, etc.

The content is, as previously mentioned, requested by the peers from an appropriate source, CDN or neighbouring peer and is subsequently received at the peers, which determines one or more metrics to be associated with the received content, for instance locality of uploading peer, video playback quality, failed uploads, failed downloads, etc. The metrics are thereafter provided to the RT server for evaluation. Any network parameter can practically be envisaged for evaluation.

Based on these acquired metrics, the RT server determines the performance of the P2P network in terms of for example savings of the content distribution source, average latency, maximum latency, etc.

Advantageously, the evaluation of the P2P network performance as performed by the RT server can remotely and silently call upon existing peers to run a content distribution event using a number of tuneable distribution parameters and evaluate the performance of the network based on a number of metrics as measured by the peers.

In a further embodiment of the present invention, subsequent to the evaluation of the P2P network performance, the RT server creates one or more modified distribution parameters based on the determined performance, and initiates a further round of distribution of content to the peers based on the modified distribution parameter(s). Advantageously, by evaluating the P2P network performance based on the metrics measured by the peers, the distribution parameters may be tuned by the RT server to accomplish a desired P2P network performance. In order to accomplish the desired P2P network performance, the RT server will create one or more modified distribution parameters accordingly and initiate a further round of content distribution based on the modified parameters. Again, the peers will be instructed to request content based on the modified parameters, receive the content accordingly, measure and report the metric, and the RT server will again advantageously determine the P2P performance as brought about by the content distributed as specified by the modified distribution parameters. Thus, with this further iteration (and possibly even further iterations) where content distribution is initiated based on modified distribution parameters, an optimization procedure is performed for the tuneable distribution parameters of the P2P network. Advantageously, after having performed a number of iterations, the so called Pareto frontier of the network may be found.

Advantageously, with the method and device according to the present invention, performance of a P2P content distribution system can be evaluated in a manner that does not require active participation of the end users of the system. Hence, a system operator is allowed to better understand the expected performance of the P2P content distribution system. Such evaluation would allow the operators to adapt their P2P content distribution strategy to existing static and dynamic conditions for maximum robustness.

In an embodiment, from a distributor of the content, at least one metric associated with the content transmitted by said distributor of the content is acquired, and the performance of the P2P network is further determined based on the acquired at least one metric associated with the content transmitted.

In a further embodiment, the at least one metric associated with the content received by the at least one peer device indicates a latency between an instant of time when said content was made available at a source of the content and an instant of time when said content is received at the at least one peer device, wherein the performance of the P2P network is determined based on the latency.

In still a further embodiment, the at least one metric associated with the content received by the at least one peer device indicating the instant of time when the content is received, and the at least one metric associated with the content transmitted by the distributor of the content indicating an instant of time when said content was made available at the source of the content, wherein the performance of the P2P network is determined based on the latency.

Further provided is a computer program for causing a device to perform the method according to the present invention, and a computer program product comprising computer readable medium having the computer program embodied thereon.

Preferred embodiments of the present invention will be discussed in the following.

DETAILED DESCRIPTION

FIG. 1illustrates a P2P network10in which a device11according to an embodiment of the present invention is implemented for determining performance of the P2P network10. The device11will in the following be referred to as a Remote Testing (RT) server, and is typically located remotely from peers12-18of the P2P network10. Further illustrated is a content distribution server19for distributing content to the peers12-18. This will in the following be referred to as a streaming source (SS). It should be noted that a real P2P network may include hundreds or even thousands of peer devices. It should further be noted that while the RT server11is illustrated as being implemented in a single node, an RT system comprising a plurality of nodes may be envisaged, which plurality of nodes upon intercommunication provide the functionality of the RT server.

In practice, the method for determining performance of the P2P network10according to an embodiment of the present invention undertaken by RT server11is performed by a processing unit20embodied in the form of one or more microprocessors arranged to execute a computer program22downloaded to a suitable storage medium21associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The processing unit20is arranged to carry out the method according to embodiments of the present invention when the appropriate computer program22comprising computer-executable instructions is downloaded to the storage medium21and executed by the processing unit20. The storage medium21may also be a computer program product comprising the computer program22. Alternatively, the computer program22may be transferred to the storage medium21by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program22may be downloaded to the storage medium21over a network. The processing unit20may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. In case of a distributed RT system as mentioned in the above, each of the plurality of nodes of the system may comprise a processing unit.

In the following, timing diagrams will be employed to illustrate various embodiments of the invention. In the diagrams, signalling is undertaken in a few steps for illustrative purposes. However, in practice, signalling in a P2P system is generally extensive and highly sophisticated with many rounds of communication occurring.

FIG. 2shows a timing diagram illustrating a method of determining performance of the network10illustrated inFIG. 1according to an embodiment of the present invention. In a practical situation, communication would typically take place between the RT server11and a large number of network peers in order to adequately determine performance of the P2P network10on the basis of measured data from a great number of peers. The measured data of the respective peer may be evaluated by the RT server11separately and/or in combination by aggregating measured data from a plurality of peers. However, in the timing diagram ofFIG. 2, the method is illustrated by means of communication with a single peer12.

In a first step S101, the RT server11initiates distribution of content to the peer12in the P2P network10by instructing the peer12to download the content from the streaming source19or, more likely due to the nature of a P2P network, from any one of the neighbouring peers13-18, the distribution of content being specified by one or more distribution parameters determined the RT server11. Generally, a set of distribution parameters are utilized to control the distribution of content to the network peers12-18. Thus, the peer12sends a request to the streaming source19or a neighbouring peer13-18to distribute content, which distributes the content to the peer12as specified by the distribution parameters submitted by the RT server11along with the instruction to the peer12to request content.

In this particular embodiment, the RT server11and the content distribution server19are separate nodes. However, it can be envisaged that the RT server11is integrated with the content distribution server19, thus forming a single node.

The content to be distributed may be embodied e.g. in the form of a simulated—or real—live streaming event with one or many specified bit rates (i.e. the same content may have to be streamed with different degrees of quality), as stipulated by the set of distribution parameters. As an example, for video distribution the specified bit rate may be 1.8 Mbps for full high-definition (HD) and 0.8 Mbps for standard HD. The same live streaming event may implement one of the above two bit rates, both, or further bit rates depending on application.

As an alternative, the content to be distributed may be embodied in the form of a real or simulated VOD streaming event with same or more specified bit rates. Further distribution parameters may comprise, as previously discussed, e.g. maximum allowable hop count of a peer from the content distribution source.

In a second step S102, the RT server11acquires from the peer12, either by receiving or actively fetching, at least one metric associated with the content received by the peer12. For instance, the network peers may measure and report metrics with a time resolution ranging from a few seconds to a minute or more. The metrics may for example comprise one or more of amount of data downloaded from streaming source versus amount of data downloaded from neighbouring peers in the P2P network, quality of video stream, number of hops away from the streaming source, playback point at the peer with respect the real-time playback point of the streaming source (to be used for calculating latency), etc.

In step S103, the RT server11evaluates the performance of the P2P network10based on the acquired one or more metrics from the peer12. For instance, network performance may be determined by the RT server11in the form of bandwidth savings, latency of received content, quality of the content, etc.

In a further embodiment, not only will the RT server11acquire, from the peer12, at least one metric associated with the content received by the peer12, but also at least one metric associated with the content transmitted as illustrated in step S102a, such as e.g. number of bytes uploaded, failed connections, failed uploads, upload data rate, etc., from the streaming source19, a neighbouring peer13, or whoever is the distributor of the content. By further taking into account one or more metrics associated with the content transmitted, even further aspects of the performance of the P2P network may be determined.

In such further embodiment, the RT server11evaluates the performance of the P2P network10in step S103based on the acquired one or more metrics associated with content received by the peer12as well as on the acquired one or more metrics associated with content transmitted by the streaming source19or a neighbouring peer13.

As previously mentioned, it should further be noted that while the method of determining performance of the network illustrated inFIG. 2is illustrated as being implemented in a single node, an RT system comprising a plurality of nodes or modules may be envisaged, which plurality of nodes upon intercommunication provide the functionality of the RT server. Hence, a first node may perform the step of S101of initiating distribution of content to the peer12, while a second node may acquire the metric from the peer12in step S102, and a third node evaluates the performance of the P2P network10based on the acquired metrics from the peer12. Thereby, a distributed system is provided, where the various nodes may be located remotely from each other, even in different parts of the world. This may require intercommunication between one or more the first, second and third nodes. Further, each one of the nodes may comprise a processing unit executing appropriate software for providing said functionality.

With reference toFIG. 3, an embodiment where the RT server11evaluates P2P network performance in the form of bandwidth savings will be discussed, even though a great number of properties stipulating network performance may be evaluated, either separately or in combination.

FIG. 3exemplifies a prior art P2P network with a single tree overlay. This is for illustrative purposes only; it should be noted that the present invention just as well may be implemented in a multi-tree and mesh-type overlays. As can be seen, peers (in practice peer devices such as television sets, mobile phones, tablets, computers, etc.) are arranged in distribution layers/levels in relation to the streaming source12. Thus, two peers are arranged at distribution level 1 one hop away from the streaming source, i.e. the level closest to streaming source, four peers are arranged at distribution level 2 (two hops away from the source) and eight peers are arranged at distribution level 3 (three hops away from the source). To illustrate, the streaming source distributes data content to peer P1, which in its turn distributes the data content to peers P3and P4. Finally, peer P3distributes the given data content to both peers P7and P8, while peer P4distributed the data content to peers P9and P10.

Hence, in such a prior art P2P live streaming network, each peer entering the network will ask a device known as a tracker (not shown) for the latest piece of data content to start streaming from as well as k randomly selected peers to be its neighbours. Then, the entering peer will turn to its neighbours for the latest piece of data content, and if it finds the required data content on any neighbouring peer, it will start streaming from that neighbouring peer. Due to network delay and asynchronicity, the entering peer will be delayed by at least the full duration of one piece of data content from its uploader and at least twice that from the streaming source on condition that the entering peer's uploader is delayed by at least the full duration of one piece of data content from the source. In other words, with respect to a real-time playback point of the data content distributed by the streaming source, the entering peer will have a latency of at least two pieces of data content, while its uploader will have a latency of at least one piece of data content. If the entering peer cannot find the latest piece of data content on one of its neighbouring peers, it will download it from the streaming source. As compared to a traditional client-server network, where the server distributes content to all clients in the network, savings in streaming source load of the P2P network inFIG. 3is 12/14=0.86. That is, instead of streaming content to all 14 peers, the streaming source streams content to two of the peers, which in their turn unload the source by streaming content to the remaining 12 peers, at the expense of network latency.

Now, with reference to that discussed in connection to the timing diagram ofFIG. 2, the RT server11initiates distribution of content in step S101to the peer12in the P2P network10by instructing the streaming source19accordingly. The distribution of content is specified by a set of distribution parameters determined the RT server11. In this particular embodiment a live streaming event is initiated by specifying quality (full HD or standard HD), bit rate (1.8 Mbps or 0.8 Mbps) and maximum number of hops from the streaming source allowed for any peer.

In the second step S102, the RT server11acquires from the peer12at least one metric associated with the content received by the peer12. In this particular embodiment, the peer12reports to the RT server11whether it has downloaded the distributed content from the streaming source or from a neighbouring peer. In that way (by receiving the metric from a great number of network peers) it is possible for the RT server11to evaluate the P2P network performance in terms of streaming source bandwidth savings.

Thus, the RT server11evaluates in step S103the performance of the P2P network10based on the acquired one or more metrics from the peer12. In this particular embodiment, the RT server11advantageously acquires information regarding from where the respective peer has uploaded the content, and determines bandwidth savings as discussed in connection toFIG. 3.

In the scenario illustrated inFIG. 3, the streaming source bandwidth savings are 12/14=0.86. The RT server11can thus assess the P2P network performance resulting from the distribution parameters initially supplied to the streaming source19for distributing the content to the peer12. If this particular exemplifying bandwidth savings measure is satisfactory, the set of distribution parameters initially supplied to the streaming source19in step S101is used by the streaming source19for distributing content. This could optionally include a step of the RT server11informing the streaming source19that the previously supplied set of distribution parameters is to be used by the streaming source19for subsequent content distribution to the P2P network peers12-18. It is important to note thatFIG. 3is used for illustrative purposes only. It is well understand that in a real P2P streaming scenario the number of peers will change over time and so will the structure of the overlay. The timing of peers joining and leaving the P2P network can be controlled by the RT server.

FIG. 4shows a timing diagram illustrating a further embodiment of the present invention, where on the basis of the determined P2P network performance, the set of distribution parameters should be slightly modified to affect the P2P network performance in line with for instance an operator's requirements. That is, if after the RT server11has determined the P2P network performance in step S103, and come to the conclusion that the performance is not as desired in line with e.g. the operator's requirements, a modified set of parameters is advantageously created by the RT server11in step S104and stored at the RT server11for future use.

It should be noted that the modified set of parameters alternatively could be stored remote from the RT server11, such as in a network storage or even distributed over a plurality of nodes in a cloud environment. If the determined P2P network performance is close to the desired performance, the set of parameters may be just slightly modified in step S104without any further rounds of acquiring metrics from the peer12.

For instance, assuming that the streaming source bandwidth savings should be slightly increased on the basis of the operator's requirements, the parameter pertaining to the maximum allowed number of distribution levels (i.e. the number of hops from the streaming source) in the network may be increased by one, or the maximum allowed streaming rate may be reduced.

Alternatively, assuming that the latency of the content rendering, with respect to a live content real-time playback point, at a peer located furthest downstream in the network (i.e. peers P7-P14inFIG. 3) should be slightly decreased, the maximum allowed number of distribution levels in the network may be decreased by one.

Again, the modifying of the at least one distribution parameter based on the determined performance of the P2P network in step S104may be performed by taking into account metrics associated with the content received by the peer12only, or by further taking into account metrics associated with the content transmitted by the streaming source19or a neighbouring peer13.

FIG. 5shows a timing diagram illustrating yet a further embodiment of the present invention, where on the basis of the determined P2P network performance, a further round of distributing content is initiated with the aim to affect, and ultimately optimize, the performance in line with for instance an operator's requirements on the P2P network performance. That is, if after the RT server11has determined the P2P network performance in step S103, and come to the conclusion that the performance is not as desired in line with e.g. the operator's requirements, a modified set of parameters is advantageously created by the RT server11in step S104. If the determined P2P network performance greatly deviates from that of the desired performance, the set of parameters may be substantially modified in step S104and submitted to peer12in step S105for initiating a further round of content distribution to the peer12specified by the modified set of parameters. The peer12will thus request and receive the content from the streaming source19or any one of the neighbouring peers13-18based on the modified set of parameters. In practice, the modified set of parameters my be distributed to all peers in the network as well as to the streaming source, since the network peers are likely to engage in uploading and/or downloading of content, and thus will conform with the set of distribution parameters in order to attain a desired performance.

For instance, assuming that the streaming source bandwidth savings should be substantially increased on the basis of the operator's requirements, the parameter pertaining to the maximum allowed number of distribution levels in the network may be increased by a greater number than one, and even further parameters in the set may be modified, if required, such as e.g. the bit rate of the standard HD distribution and the full HD distribution or even a parameter stipulating a completely different content to be distributed.

Similar to the embodiment of the present invention described with reference toFIG. 2, the RT server11acquires from the peer12in a further step S106at least one metric associated with the content received by the peer12, the content being specified by the modified set of distribution parameters, in this particular example specifying whether the uploader is a neighbouring peer or the streaming source19.

In step S107, the RT server11determines the performance of the P2P network10based on the new acquired metric from the peer12. If the performance is considered to be as desired, the RT server11advantageously concludes that the modified set of parameters should be used by the streaming source19or neighbouring peers13-18for subsequent content distribution. If not, another round of modifying the distribution parameters will be undertaken. By initiating a plurality of rounds of content distribution based on carefully selected distribution parameters and acquiring resulting metrics from the peers, the performance of the P2P network can advantageously be increased or even optimized.

It should be noted that in order for the peers12-18to be able to report desired metrics to the RT server11, it may be necessary to equip the peers with an appropriate content rendering element, e.g., by installing an appropriate piece of software at the respective peer12-18, which can mimic the behaviour of a peer device media player rendering the received content, unless the measuring and reporting of the metric(s) in fact are performed by the peer during a “normal” content distribution as specified by distribution parameters supplied by the RT server11. However, in any case, the peer devices12-18may have to be equipped with the appropriate software functionality for being able to report adequately to the RT server11. The peer devices12-18of the P2P network10may further be capable of communication with each other in order to procure desired metrics for reporting to the RT server11.

Further, the metric reports acquired by the RT server11from the peers12-18may be complemented by the streaming source19reporting one or more properties to the RT server11such that the P2P network performance can be determined, e.g. number of bytes uploaded, failed connections, interrupted streams, etc.

FIG. 6shows a timing diagram illustrating still a further embodiment of the present invention, where the determining of the P2P network performance undertaken by the RT server11is performed as part of a “normal” content distribution procedure in the P2P network. Typically, each of the peers12-18request content and is either supplied content from the streaming source19or more commonly, given the nature of a P2P system, from one or more neighbouring peers.

In step S100, the RT server11receives an indication from the streaming source19or a neighbouring peer13-18that one or more requests for content is received from the peer12. Alternatively, the request is received directly from the peer(s) which desires to download content. As in the embodiments of the invention described with reference to the previous timing diagrams, the RT server11initiates in step S101distribution of the requested content to the peer12in the P2P network10by signalling accordingly to the peer12, the distribution of content again being specified by the set of distribution parameters determined the RT server11. The streaming source19or neighbouring peer13-18subsequently distributes the requested content to the peer12as specified by the distribution parameters submitted by the RT server11.

In a second step S102, the RT server11acquires from the peer12at least one metric associated with the content received by the peer12and determines in step S103the performance of the P2P network10based on the acquired one or more metrics from the peer12, as previously has been described in detail.

Moreover, even though the timing diagrams inFIGS. 2, 4 and 5illustrate reporting of metrics of a single peer12to the RT server11, a great number of peers will in practice be utilized for the metrics reporting, and the RT server11will aggregate the reported metrics in order to determine the P2P network performance. Aggregated metrics may include, in addition to the previously mentioned exemplifying metrics, playback quality (i.e. what percentage of peers on average watched the highest quality video with the highest bit rates as compared to a second highest quality, switching frequency (i.e. how often peers switch between different quality streams), etc.

FIG. 7illustrates the RT server11in more functional detail. Again, as was discussed with reference toFIG. 1, functions of the RT server are typically embodied by a processing unit in the form of one or more microprocessors arranged to execute a computer program downloaded to a suitable storage medium associated with the microprocessor. The processing unit may alternatively be embodied in the form of a DSP, an ASIC, an FPGA, a CPLD, etc.

A Test Initiator (TI)30of the RT server11determines that performance of the network10is to be improved, or even optimized, with respect to one or more network performance aspects, such as for instance:1) Minimize streaming source(s) bandwidth consumption,2) Minimize live streaming latency,3) Maximize locality (i.e. keeping network traffic local), or4) Maximize Quality of Service (QoS).

The TI30will thus select a subset of the peer devices12-18to be included in the test, and initiate distribution of content in step S101to the subset of peers, in this case exemplified by the single peer12. Typically, hundreds or even thousands of peer devices may be included in the network10, while some ten or twenty will be included in the subset to be tested.

The distribution of content is specified by at least one distribution parameter controlling the performance. Assuming for instance that task 2) hereinabove is a performance aspect to be optimized: live streaming latency is to be minimized.

The distribution parameter controlling the performance may thus be embodied by a locality parameter. That is, the peer12is to turn to another peer or the streaming source19considering the locality parameter and thus select a content distributor resulting in low latency. Additionally or alternatively, the distribution parameter may for instance indicate type of content to be distributed, for instance whether the distributed content is audio and/or video, which may have an impact on the subsequently determined latency.

As an example, assuming that a first peer13is located closer to downloading peer12as compared to a second peer14or the streaming source19. The downloading peer12will thus consider the distribution parameter (“locality”) and turn to the first peer13, even if the first peer13, e.g., would provide a lower QoS than the second peer14upon the downloading peer12rendering the live content streams.

In step S102, a Data Collection (DC) back-end31of the RT server11acquires, from the downloading peer device12, at least one metric associated with the content received. For instance, since live streaming latency is to be minimized under 2), the metric associated with the received content may be embodied in the form of a timestamp T1indicating an instant of time when the requested content is received (or even when it is rendered by the downloading peer device12should there be a non-negligible time difference between the instant of receiving the content and the instant of rendering the received content).

Further in step S102a, the DC back-end31of the RT server11acquires, from the uploading first peer device13, at least one metric associated with the content transmitted. In this example, a timestamp T2indicating an instant of time when the very same content was made available at the streaming source19. Assuming that a live sports event is streamed; the latency to be determined is thus the difference between the instant when an action takes place in real time and the instant when the same action in fact is rendered by a peer device (in practice typically coinciding with the instant in time when the content is received). For instance, this latency may be exemplified as the difference between the (real) time when a football striker scores a goal and the time when a viewer actually sees it happen on his or her screen.

These two metrics—i.e. timestamps T1and T2—are passed on to a Performance Analyser (PA)32of the RT server11which determines in step103the performance of the network in accordance with the performance aspect under test. In this particular embodiment, the performance—exemplified by live streaming latency—is determined as:

Now, if the PA32determines in step S103that the latency is minimized (or at last good enough), the test is terminated by an Optimal Parameter Tuner33of the RT server11, and it may advantageously be determined for instance that the downloading peer12and a number of neighbouring peers being proximate to the downloading peer12(for instance being located in a same district or geographical area of a city) is to download content from the second peer device13.

If not, the OPT33will in step S104modify the at least one distribution parameter based on the determined performance of the P2P network10, such that the modified at least one distribution parameter is configured to control performance of the P2P network according to P2P network performance requirements and inform the TI30accordingly.

In this example, the locality parameter is modified such that the TI30initiates another round of distribution of content in step S106to the downloading peer12, where the downloading peer12attempts to request content from a third peer device17providing a decreased live streaming latency as compared to the first peer device13.

Hence, in step S106, the DC back-end31of the RT server11acquires, from the downloading peer device12, the metric associated with the content received in the form of a timestamp T3indicating an instant of time when the requested content is received from the third peer device17(or when the requested content actually is rendered at the downloading peer device12as previously discussed).

Further in step S106a, the DC back-end31of the RT server11acquires, from the uploading third peer device17, at least one metric associated with the content transmitted. In this example, a timestamp T4indicating an instant of time when the requested content was made available at the streaming source19is acquired. It should be noted that timestamp T4previously has been provided to the uploading third peer device17, either from the streaming source19itself or via any other peer device uploading the requested content to the third peer device17.

These two metrics—i.e. timestamps T3and T4—are passed on to the PA32of the RT server11which determines in step107the performance of the network in accordance with the performance aspect under test. Again, in this particular embodiment, the performance—exemplified by live streaming latency—is determined as:

Again, if the PA32determines in step S107that the latency is minimized (or at last good enough), the test is terminated by the OPT33of the RT server11, and it may advantageously be determined for instance that the downloading peer12and a number of neighbouring peers being proximate to the downloading peer12(for instance being located in a same district or geographical area of a city) is to download content from the third peer device17.

It should be noted that in an embodiment where only the downloading peer device12, and not the streaming source19or any other uploading peer device13, reports metrics to the RT server11as previously has been described, either the streaming source19or any uploading peer device13may provide the downloading peer device12with a metric associated with the content transmitted to the peer device12. For instance, in case of optimizing performance of the P2P network with respect to latency as described with reference toFIG. 7, the timestamp T2(and T4in case of an iterative behaviour) must be reported to the downloading peer device12from the streaming source19or any uploading peer13, such that the RT server11may determine the latency.

With regards to selecting one or more peer devices to which distribution of content is to be initiated, and from which one or more metrics are to be acquired, a number of embodiments are envisaged.

In the following, a number of peer device selection strategies are envisaged:

1. No selection of peer devices is undertaken; distribution of content is initiated to all available peers.
2. Distribution of content is initiated for a number of peer devices in a network segment corresponding to an expected number of actual viewers, where a segment/site is embodied for instance in the form of a district or geographical area of a city, a particular building, a particular enterprise spread over a number of physical offices, etc.
3. Proportional with respect to size of a segment/site size, where the number of peer devices (randomly) selected from each site/network segment is set to be proportional to the expected number of viewers in that segment. For example, if network segment A has an expected number of viewers of 10000 and segment B has 50000; a test run may specify a proportion of 10%, and include 1000 peer devices from segment A and 5000 peer devices from segment B.
4. Proportional with respect to client type. Thus, the selection takes into account peer device hardware, operating system, memory and bandwidth capacity, etc. Then, peer devices are selected in proportion to expected client type in a live streaming scenario.

A combination of one or more of the above listed strategies can further be envisaged.