# Neighbor selection strategies in the wild for CDN/V2V WebRTC live streaming: Can we learn what a good neighbor is?

Zhejiayu Ma, Frédéric Giroire, Guillaume Urvoy-Keller, Soufiane Rouibia

► To cite this version:

Zhejiayu Ma, Frédéric Giroire, Guillaume Urvoy-Keller, Soufiane Rouibia. Neighbor selection strategies in the wild for CDN/V2V WebRTC live streaming: Can we learn what a good neighbor is?. Computer Networks, 2026, 274, pp.111783. 10.1016/j.comnet.2025.111783. hal-05359394

HAL Id: hal-05359394

https://hal.science/hal-05359394v1

Submitted on 11 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Neighbor Selection Strategies in the Wild for CDN/V2V WebRTC Live Streaming: Can we learn what a good neighbor is?

Zhejiayu Ma<sup>a,b</sup>, Frederic Giroire<sup>a</sup>, Guillaume Urvoy-Keller<sup>a</sup>, Soufiane Rouibia<sup>b</sup>

<sup>a</sup>Universite Cote d'Azur, CNRS, Inria, I3S laboratory, Sophia Antipolis, France

<sup>b</sup>EasyBroadcast, Nantes, France

## Abstract

A hybrid CDN/Viewer-to-Viewer (V2V) architecture is an attractive solution for HTTP (HLS) and MPEG-DASH-based live streaming providers. It combines a traditional CDN with a V2V overlay for exchanging video fragments, reducing the CDN costs while maintaining the quality of experience. This work explores machine learning models to address the key challenge of neighbor selection. Our goal is to predict the connection quality between two arbitrary viewers using features such as locality, access providers, operating systems, past CDN, and V2V throughput. The proposed solutions are validated using an A/B testing approach on our production system and demonstrate a significant improvement in key system metrics compared to the traditional locality-based methods. We observe 17% higher V2V throughput, 26% lower delay, 37% fewer lost chunks, 39% fewer rebuffering, and 20% fewer quality switches.

**Keywords:** hybrid P2P, live streaming, peer selection, machine learning, real deployment, A/B testing

## 1. Introduction

The video streaming traffic represents an increasing fraction of Internet traffic with a compound annual growth rate of 34% between 2017 and 2022, according to Cisco [1]. Live streaming and VoD (Video On Demand) are two common ways to stream video online. With the rise of HLS<fnref n="1" /> and DASH<fnref n="2" />, PC and mobile users benefit from the convenience of HTTP-based streaming protocol for day-to-day entertainment. One important challenge is maintaining the quality of the service despite this increasing audience. Content delivery networks (CDNs) are a cornerstone component provided by many companies such as Akamai, Amazon, Google, and Azure [2, 3, 4, 5].

However, the cost of maintaining CDN servers or purchasing services from providers becomes high as the audience grows [6]. To further reduce the costs, a viewer-to-viewer (V2V) overlay has been introduced into the live streaming and over-the-top (OTT) services with the maturing of WebRTC. WebRTC allows data exchange between browsers, and it greatly facilitates the deployment of such hybrid systems. With the help of WebRTC, V2V traffic can offload a significant fraction of the traffic from the CDN servers, consequently reducing the operational cost. Examples of such services or systems are: Limelight Huang et al. [7], Akamai, LiveSky Yin et al. [8], or EasyBroadcast [9].

Therefore, the P2P network was introduced to take advantage of the large audience. It is proven that the serviceability of the P2P network grows exponentially during the bootstrap phase Xiangying

<footnote n="1">¹Apple's HTTP Live Streaming (HLS)</footnote>

<footnote n="2">²Dynamic Adaptive Streaming over HTTP.</footnote>
Yang and de Veciana [10], showing the huge potential of using P2P technology to help with large-scale multi-media diffusion. CoolStreaming Xie et al. [11] and UUSee Wu et al. [12] are two well-known examples. However, the pure P2P network suffers from the dynamics problems, including the flash crowd and peer churn disrupting the video diffusion across the P2P overlay Jiangchuan Liu et al. [13]. These problems might cause the video players to stall and impair the Quality of Experience (QoE).

Consequently, it is motivational to take the best of both worlds and form a novel solution. The hybrid CDN/V2V (Viewer-to-viewer) is thus suggested by various literature. The hybrid CDN/V2V architecture can handle the flash crowd and QoE (Quality of Experience) disruptions Xu et al. [14]. The examples of this type of system are: Limelight Huang et al. [7], Akamai, LiveSky Yin et al. [8] and EasyBroadcast [9]. The rise of HTTP-based streaming comes with the rise of browser video players (HLS, Dash). Furthermore, the enabling factor for CDN/V2V in browsers is the maturing of WebRTC technology. WebRTC allows the inter-connection between browsers with a hole-punching technique: ICE. It greatly facilitates the deployment of hybrid CDN/V2V networks. The videos are diffused through the CDN and V2V overlay whenever available in such a hybrid system. This mechanism helps reduce up to 80% of the load from CDN, consequently reducing the operational cost. Just as maintaining a traditional pure P2P network, an overlay management/construction needs to be devised. There are tree-based architecture Jiangchuan Liu et al. [13], Zhang et al. [15], Xie et al. [11].

The overlay construction is a demanding task that has been broadly investigated in the context of Peer-to-Peer (P2P) networks<fnref n="3" />. The dominant approaches are tree-based [13, 15, 11], mesh-based [16, 17], and tree-mesh overlays [18]. A tree-based overlay is known for its low overhead and its difficulty handling load fluctuations, such as flash crowd and peer churn, that can break the diffusion tree. Alternatives are mesh-based and hybrid overlays. In a mesh-overlay, neighborhoods are constructed at random. Many studies have been proposed to improve this baseline strategy, e.g. morphing the overlay into a hybrid tree-mesh overlay [19, 18] or mesh overlay organization including hierarchical structure creation, or locality-awareness [20, 21, 22, 23, 24]. The recent work [25] proposes an online learning approach, RICHTER, to design an efficient Hybrid P2P-CDN Architecture.

Constructing an effective V2V overlay for a hybrid CDN/V2V live streaming system, however, bears unique challenges. Firstly, the traditional P2P live streaming requires the chunks to be majorly provided by the peers Xie et al. [11], Wu et al. [12], Li and Niu [26]. In contrast, in a hybrid system, the diffusion tree is shallower because the missing chunks can always be fetched from the CDN. Secondly, one essential characteristic of live streaming is that users need to be synchronised with the playback head. Hence, during a short period of time (typically less than 10s), the majority of users seek the same set of video chunks.

The *immediate* neighborhood thus highly determines the efficiency of the V2V system. A key challenge is then to predict the performance between one viewer and its *immediate* neighbors and use this information to select neighbors. Legacy approaches focus on proximity metrics such as the same ISP, city, country, or the smallest geographical distance. We compare these strategies with a machine learning (ML) approach in this work.

Our contributions are the following:

(1) We proposed different ML models to predict the throughput between two viewers. These models are based on different information such as locality, ISP, operating systems, past CDN throughput, and V2V throughput.

<footnote n="3">³We interchangeably use the notion of peer or viewer, where a viewer is a WebRTC client that can be seen as a special type of peer.</footnote>
(2) We implemented these models in an operational hybrid CDN/V2V live streaming web application with tens of thousands of viewers per day in North Africa and Europe. To the best of our knowledge, we are the first to investigate the behavior of neighbor selection strategies in a real-world hybrid CDN/V2V live streaming setup, as well as their impact on QoE.

(3) We tested and compared the different peer selection strategies (random, locality-based, and ML-based) in production during several A/B testing campaigns. These deployments demonstrate that

(a) locality features are key features;

(b) learning-based methods can significantly improve the performances of a hybrid streaming system as compared to legacy approaches;

(c) improving throughput has indirect important side advantages: it improves delay, chunk losses<fnref n="4" />, re-buffering, quality switches.

The paper is structured as follows: In Section 2 we present the considered neighbor selection policies, the system characteristics, the A/B testing strategy, and the metrics used to measure the effectiveness of the policies. Section 3 discusses the features, the model training, and its deployment. Section 4 presents the aggregate and detailed results of several A/B tests. Finally, we present the related work in Section 5 and the conclusions in Section 6.

## 2. System overview and experiment planning

This section presents several traditional neighbor selection policies, our ML-based neighbor selection policies, the architecture of our OTT streaming service system, and the proposed ML-based neighbor selection policy used for predicting the V2V connection quality. We further discuss the A/B testing setup and the evaluation metrics.

### 2.1. *Classic Neighbor Selection Policies*

The neighbor selection policy determines the overlay structure of the mesh network and, as such, the efficiency of the V2V overlay. We investigate several of them: random, locality-based, and ML-based neighbor selection policies.

#### 2.1.1. *Random Neighbor Selection*

This policy selects uniformly at random peers from the same bucket<fnref n="5" /> as candidate neighbors, see Algorithm 1. The mesh overlay constructed in this manner is a random mesh.

#### 2.1.2. *Locality-Based Neighbor Selection*

Unlike random neighbor selection, the locality-based neighbor selection considers geographic information. We study three methods: *Geo* neighbor selection, *Geo-ISP* neighbor selection, and *Geo-Distance* neighbor selection. As the name implies, *Geo* neighbor selection considers only the geographic information. It prioritizes the peers in the following order: (1) peers from the same city, (2) peers from the same country, (3) peers from the same continent (4) peers from another location. *Geo-ISP* picks

<footnote n="4">⁴A chunk loss event corresponds to the case in which a video chunk is not received fast enough from a neighbor viewer, forcing to revert to the CDN server.</footnote>

<footnote n="5">⁵Bucket A or B relates to the set of viewers under policy A or B in the A/B testing approach.</footnote>
peers from the same ISP in priority and then ranks them as *Geo*. Last, *Geo-Distance* bases its selection on the estimated geographic distance between the viewers' cities.

Similarly, we define the Geo Peer Selection (Geo) in Algorithm 2. The Geo matches the peers in the following order: (1) same city (2) in the same country but not in the same city (3) same continent but not the same country.

<caption>**Algorithm 1: Random Peer Selection**</caption>

**Data:** *S* = Potential Neighbor Set
**Result:** *R* = Selected Neighbor Set
**for** *i* = 0; *i* < 10; *i* = *i* + 1 **do**
> Take random element *p*₂ from *S*;
> Add *p*₂ to *R*;
**end**

<caption>**Algorithm 2: Geo Peer Selection**</caption>

**Data:** *S* = Potential Neighbor Set, *p*₁ = Current Peer, *N* = Sample Size
**Result:** *R* = Selected Neighbor Set
**Function** GeoScoring(*R*'):
* Scores ← Empty List
* for *p*₂ in *R'* **do**
  * s ← 0
  * if *p*₁ in the same city as *p*₂ **then**
    * s ← s + 1;
  * end
  * if *p*₁ in the same country as *p*₂ **then**
    * s ← s + 2;
  * end
  * if *p*₁ in the same continent as *p*₂ **then**
    * s ← s + 4;
  * end
  * Scores ← Scores + *s*
* end
* return Scores;

*R' ← Empty Set;
**for** *i* = 0; *i* < *N*; *i* = *i* + 1 **do**
> Take random element *p* from *S*
> Add *p* to *R'*
**end**
*return* Top10Peers(GeoScoring(*R'*))

<caption>**Algorithm 3: Geo-ISP Peer Selection**</caption>

**Data:** *S* = Potential Neighbor Set, *p*₁ = Current Peer, *N* = Sample Size
**Result:** *R* = Selected Neighbor Set
**Function** GeoISPScoring(*R*'):
* Scores ← Empty List
* for *p*₂ in *R'* **do**
  * *s* ← 0
  * if *p*₁ in the same city as *p*₂ **then**
    * *s* ← *s* + 1;
  * end
  * if *p*₁ in the same country as *p*₂ **then**
    * *s* ← *s* + 2;
  * end
  * if *p*₁ in the same continent as *p*₂ **then**
    * *s* ← *s* + 4;
  * end
  * if *p*₁ in the same ISP as *p*₂ **then**
    * *s* ← *s* + 8;
  * end
  * Scores ← Scores + *s*
* end
* return Scores;

*R' ← Empty Set;
**for** *i* = 0; *i* < *N*; *i* = *i* + 1 **do**
> Take random element *p* from *S*
> Add *p* to *R'*
**end**
*return* Top10Peers(GeoISPScoring(*R'*))

### 2.1.3. Geo-ISP Policy

As defined in Algorithm 3, the Geo-ISP policy is an extension to Geo where we include one more score from ISP.
<figure><img src="image_2.png" /><figcaption>Figure 1: The system architecture diagram showing how A/B testing splits two groups of randomly assigned viewers.</figcaption></figure>

## 2.2. System architecture

In the OTT system under study, the viewers run a client-side JavaScript library loaded when the client lands on the channel's web page. The library then contacts a central tracker that provides a list of candidate neighbors, with which a WebRTC channel web [27] will be established. In addition, the client's library further regularly reports logs of statistics related to the transfers from the CDN or its neighbors in the overlay to a centralized database.

There are four servers to collect the logs, run the tracker, update the ML model using a Tensorflow Serving server [28], and a feature store which is a feature aggregation service discussed in Section 3.1.4.

The log server is hosted in a public cloud in terms of physical infrastructure. The tracker runs on a dedicated physical server while the online feature store and the Tensorflow Serving server share a second physical server. These physical servers feature 4 CPUs and 16GB of RAM. Figure 1 provides a high-level diagram of the system. The current setup served up to 30 000 simultaneous viewers during the experiments.

The central tracker can use either the various neighbor selection policies presented in the previous section (Section 2.1) or ML-based neighbor selection presented below.

### 2.2.1. ML-based neighbor selection

The ML neighbor selection is a data-driven method that learns a scoring function estimating the future potential throughput between two peers. The peers with the ten highest scores are then selected. The motivation for using ML is to make a decision based on more additional information to overcome the drawbacks of **single-criteria policies**. One example is that the locality-based method might not be optimum to select a peer from the same city and ISP if that peer has a poor device or is experiencing a bad connection. In contrast, peers geographically far (i.e., from another city or a different ISP) with a better device and upload capacity could benefit the current peer. Thus, we explore neighbor selection
policies using **additional information** such as device type, watched channel, CDN throughput, and historical upload throughput. The full features and the ML method are discussed in detail in Section 3.

Note that there is a random phase of the Geo, Geo-ISP, and ML limits the number of peers to evaluate all the policies, and by limiting the peers for scoring, the algorithms will not be able to find the global optimum, as only a tiny proportion of peers are taken out for evaluation. On the one hand, because of the limited resources, we limited the initial random set to only 100 viewers. As we know, given $N$ peers, the complexity of a complete pair evaluation is $O(N^2)$. Even though caching provides a tangible way to speed up the request, its effectiveness is limited to the case when the value of the input features does not change. Nevertheless, the numerical features keep changing, rendering the caching ineffective. Thus, this becomes quite expensive to evaluate the entire pair set. On the other hand, the model finds the top peers (with lower percentile rank, better throughput). Proportionally, the model should find top peers when we do a large sampling setting and eventually sample 100% of the potential neighbor set when the resources are abundant. For instance, during one of the experiments, we pre-sampled 100 peers. We observed that around 3 CPUs and 2GB of memory were needed for the inference engine during 20,000-simultaneous viewers' live streaming events, yielding more than 2,000 peer selection requests per second. Thus, our experiment focuses on a 100 sample peer selection comparison instead of the whole pair evaluation. We argue that the result is still valid because this random phase of peer selection is applied to all the policies evaluated$^6$.

## 2.3. Channel properties

We tested the models against multiple north-African TV channels serviced by our OTT system. The users watch the channels from their mobile devices (30%) or desktops (70%) with an HLS player serviced by our OTT library that transparently downloads chunks from other viewers or the CDN server. They are distributed across different countries as 45% of users are from Morocco, 17% users are from France, and the rest is from other African and European countries.

The channels have three qualities available. The highest (resp. medium and lowest) quality chunk size is, on average, 1.3MB (resp. 800KB and 500KB). The HLS web player selects the quality according to the bandwidth available and the practical video buffer level. In general, all channels experience a peak audience at around 18:00 UTC.

## 2.4. A/B testing

It is non-trivial to experiment in a production environment involving real users because the confounding variables are omnipresent, such as the number of users per day, the changes in the network conditions, and the content streamed. These variables influence the watching time, QoE, and QoS, making the comparison of peer selection policies difficult. The result from sequential policy testing can also be misleading for the same reason. We argue that it is essential to compare policies with similar traffic and similar network conditions side by side. A/B testing is a methodology designed to address this issue.

In A/B testing, it is required to state the stable unit treatment value assumption (SUTVA) [29] that requires that each individual's response is affected by their treatment only. In our experiments,

<footnote>$^6$During our study, we wanted to (i) obtain a model to evaluate a good neighbor without using preconceived notions of what a good neighbor is, (ii) compare the different policies (random selection, locality-based selection) in a fair way without considering only good neighbors for some policies. Thus, we used the policy of uniformly randomly selecting the N potential neighbors in order not to introduce any bias at this stage and to obtain a representative sample. However, in a future stage, once the efficiency of ML methods has been validated, it could be beneficial for the system to include some rule-based filters to avoid taking potential neighbors that are consistently bad.</footnote>
the peers are randomly assigned to one of the two different neighbor selection policy buckets. The peers are only matched to others within the same bucket. As shown in Figure 1, the tracker randomly groups the peers into two separate buckets. Therefore, we can establish a causal relationship between the neighbor selection policies and the difference observed in different metrics. The metrics we rely on to assess the efficiency of the neighbor selection policy (QoS and QoE) are presented in the next section.

## 2.5. QoS and QoE Metrics

The metrics can be classified as Quality of Service (QoS) and Quality of Experience (QoE) metrics.

### 2.5.1. V2V Throughput (QoS)

The V2V throughput between peers $p_2$ and $p_1$ is measured using the chunks uploaded from $p_2$ to $p_1$. $AvgTP_{p_1,p_2} = \sum B_{p_1,p_2} / \sum T_{p_1,p_2}$. In the equation, $\sum B_{p_1,p_2}$ refers to the total bytes of the chunks uploaded from $p_2$ and downloaded to $p_1$ during the whole session. Similarly, $\sum T_{p_1,p_2}$ refers to the total time spent waiting for the chunks uploaded from $p_2$ to $p_1$.

### 2.5.2. End-to-End Delay (QoS)

In addition to the V2V throughput, we are also interested in lowering the end-to-end delay (DL). Indeed, the lower the delay between two viewers is, the faster the availability information$^7$ is disseminated, leading to a potential increase of the V2V ratio. We measure this metric using the average round-trip time of lightweight ping-pong messages (a few bytes) exchanged on the WebRTC channel between neighbors by the library. It is reported every 30 seconds by the viewers.

### 2.5.3. Chunk Loss Rate (QoS)

The Chunk Loss Rate (CLR) is a crucial QoS metric to assess the system. It is defined as $L = 1 - \frac{R}{S}$, where R is the number of chunks sent and S is the number of chunks received during the time of the measurement (1 day). We chose one day because the channels show similar audience day-to-day patterns.

A chunk loss is due to a timeout when receiving the chunk from a seeder. In such a situation, the peer falls back to the CDN, reducing the utility of the V2V network. The timeouts may come from the choice of bad neighbors. Thus, a high CLR indicates a potentially poor peer selection strategy.

### 2.5.4. V2V ratio (QoS)

The fraction of chunks exchanged in V2V (V2V Ratio) is a critical KPI of a hybrid CDN/V2V system because it directly translates into the monetary cost for the content owner.

### 2.5.5. Re-buffering per User (QoE)

The Re-buffering per User (Rebuf) is an objective measurement of users' experience. It occurs when the video playback buffer becomes empty. We measure the average number of re-buffering events observed by each viewer during the day of the experiment. Rebuf is calculated as $Rebuf_{d,p,i} = \frac{\sum_{i}^{M} R_{d,p,i}}{M}$ where $R_{d,p,i}$ is the number of re-buffering event for peer i in the neighbor selection policy p for the day d.

<footnote>$^7$A peer notifies its neighbors when it has received a new chunk.</footnote>
<table><caption>Table 1: The evaluated features.</caption><thead><tr><th>Name</th><th>Description</th><th>Type</th></tr></thead><tbody><tr><td>city</td><td>The name of the city</td><td>Categorical</td></tr><tr><td>country</td><td>The name of the country</td><td>Categorical</td></tr><tr><td>continent</td><td>The name of the continent</td><td>Categorical</td></tr><tr><td>isp</td><td>The name of the ISPs</td><td>Categorical</td></tr><tr><td>channel</td><td>The name of the stream</td><td>Categorical</td></tr><tr><td>devices</td><td>The device-to-device type</td><td>Categorical</td></tr><tr><td>downlinkCDN</td><td>The CDN throughput of the peers</td><td>Numerical</td></tr><tr><td>uplinkAvg</td><td>The latest IP's average upload throughput</td><td>Numerical</td></tr><tr><td>uplinkPi</td><td>Various latest IP's upload throughput of different percentiles</td><td>Numerical</td></tr><tr><td>uplinkStd</td><td>The latest IP's upload throughput's standard deviation</td><td>Numerical</td></tr></tbody></table>

### 2.5.6. Average Chunk Size (QoE)

As discussed in Section 2.3, the average chunk size (AvgCS) indicates the video quality. Each channel is available in three qualities related to three chunk sizes. Therefore, the higher the average chunk size is observed, the higher the viewers' watching quality.

### 2.5.7. Quality switch (QoE)

It is the average number of times a viewer switches from higher quality to lower quality and vice versa during the watching session. The metric measures the global quality fluctuations observed for the audience. The smaller the value is, the more stable the streaming experience is for the user.

## 3. Features Evaluation and Training

This section introduces the set of features used in our different ML models and their cross-validations and discusses the duration of the training phase.

### 3.1. Feature Set

Our algorithm uses the classic locality features: city, country, continent, and ISP information. We present the additional features here.

#### 3.1.1. Channel

Different contents significantly differ in user behavior, network conditions, device usage, and user location in a multi-channel streaming service. For instance, when considering the operating systems for two different channels in our channel bundle, 42% of users use Windows in the first one compared to 36% in the second one. Also, 39% use Android in the first channel versus 56% in the second. Geographically, 46% of users are from Morocco and 13.6% from France in the first channel; 65% of
<figure><img src="image_3.png" /><figcaption>(a) CDF of throughput for different channels. Each of line represents measurements of one unique channel. The radio channels have lower throughput.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>(b) CDF of throughput for different device pairs. For instance, Android←Windows refers to the V2V throughput measured for the chunks sent by Windows users to Android users.</figcaption></figure>

<caption>Figure 2: Distribution of the V2V throughput for different channels and device types.</caption>

users are from Morocco and 10% from France in the second. Furthermore, in terms of geographic distribution, we observe that a large percentage of users of the first channel comes from the top cities in Morocco: Casablanca and Rabat (27%). In contrast, only 18% originate from these two cities in the second channel. Moreover, the CDF shown in Figure 2a underlines the distinctive throughput experienced by clients for different channels. It confirms the intuition of using the content (token) as a feature input. One of the concerns is that content providers can create new content in many live streaming systems. The one-hot encoded content token can still handle the new tokens as pre-defined value “others.” Though the precision will not be as high, we argue that as the service continues, the performance will be improved as the data is collected and the model trained.

### 3.1.2. Device types

As discussed above, some channels feature more PC users, and some see majorly mobile users. It is essential information since the WebRTC functionalities differ among devices. For instance, as shown in Figure 2b, the MacOS-to-MacOS links observe higher throughput values than other device-to-device types. In addition, an Android user could benefit from an improved V2V throughput if it is connected to and receiving chunks from a PC user instead of another Android user. Consequently, we included tokens representing the device type in our feature set.

### 3.1.3. CDN throughput

Apart from the one-hot encoded features, we also consider numerical features. One of them is the CDN throughput. It can be easily measured from the onset of the session since the first chunks are always fetched from the CDN to ensure a short start-up time. As the CDN server has good Internet connectivity and usually is close to the user, the CDN throughput reveals key information on the quality of the access link of the user. We observed that the Pearson correlation between the logarithm of CDN throughput and the target is high (0.5). Note that as internet bandwidth approximately follows a Pareto (or exponential) distribution [30], we consider the logarithm of this value, a typical approach used in feature engineering when processing such distribution.

### 3.1.4. Historical upload throughput

While the CDN throughput informs the model of how fast one can download and, thus, provides some information about the peer's link quality, it does not uncover how fast one can upload. Ideally, we use the upload throughput as a feature, and it is frequently considered as an input in a peer selection
<figure><img src="image_5.png" /><figcaption>Figure 3: Distribution of the number of chunks sent per 30s for peers with different watching times.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Figure 4: Cross-Validation results of the different feature sets. The mean percentile rank (MPR) and the average throughput of the selected neighbors are reported. The feature set $fs_4$ yields the best results.</figcaption></figure>

model as discussed in da Silva et al. [31], Wang and Lin [32]. However, we do not have direct access to its value. The library loaded by the client measures and reports the download and upload throughput of each successful exchange. It allows us to estimate the peer upload throughput. Each viewer reports its chunks exchanged to the stats database (BigQuery), as shown in Figure 1. The feature store (Feast fea [33] aggregates the data to obtain statistics of each IP address. The initial statistics are the average, the standard deviation, the $10^{th}$, $25^{th}$, $50^{th}$, $75^{th}$, $90^{th}$ percentiles of the upload throughput over the last hour during which the peer exchanged chunks. In practice, we only use the average upload throughput (Pearson correlation = 0.59) and its standard deviation (Pearson correlation = 0.47). Indeed, the other throughput percentiles do not help much as they are colinear with the formers.

One might argue that there exists a risk of underestimating the upload throughput if the seeder does frequent parallel uploading, as the seeder upload capacity is shared among the leechers in this case. To estimate the potential impact, Figure 3 shows the number of chunks sent every 30 seconds for different categories of peers. On the left side (blue curve) are the peers staying less than 10 minutes. 90% of the time, they send less than five chunks every 30 seconds. On the right side (red curve) are the peers staying longer than 30 minutes. 80% of the time, they send less than seven chunks every 30 seconds. Furthermore, the inter-quartile range for the time to download a chunk is 2.2 and 4 seconds. Hence, parallel uploading exists but is not a massive phenomenon. Using as a feature the past average (and not the maximum) upload bandwidth leads not to selecting a peer with a very high upload bandwidth but one that is already serving many other peers, leading to some parallel uploads. This way, we naturally avoid saturating good seeders.

## 3.2. *Cross-validation*

We are interested here in testing different combinations of the features listed previously. We crafted four incremental feature sets ($fs_1$ – $fs_4$) and assessed their utility using cross-validation:

1. $fs_1$ includes geo-location and ISP of both peers$^8$;

2. $fs_2$ includes $fs_1$, the channel, and the devices of both peers;

3. $fs_3$ includes $fs_2$ and the CDN download throughput of both peers;

4. $fs_4$ encompasses $fs_3$ and the upload throughput measurements of the seeder.

Cross-validation help finds the best feature set to select the best possible neighbors, i.e., lower mean percentile rank (MPR) when peers are sorted by their upload throughput. We should ideally find the

<footnote>$^8$All categorical variables are one-hot encoded</footnote>
<figure><img src="image_7.png" /><figcaption>Figure 5: Cross-validation results for the training of the model with the N previous days of data. The mean percentile rank (MPR) and the average throughput of the selected neighbors are reported. The performance stabilises for $N \ge 14$.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Figure 6: The neural network structure. The categorical variables are one-hot encoded and then concatenated with the throughput features. A classical fully connected neural network is trained to predict the potential throughput between two viewers.</figcaption></figure>

peers with MPR = 0.1, i.e., peers in the 10th percentile. The result of the cross-validation is presented in Figure 4. Note that the $fs_1$ and $fs_2$ have MPRs around 0.35, which means the neighbors ranked before the 35th percentile. By incorporating the CDN throughput, the model gets significantly better. With the help of the upload throughput, we further improved the model, with the MPR reaching 0.19. The best feature set is $fs_4$ for the model. Our experiments allow us to test this in the wild.

### 3.3. Training duration

Here we discuss how much historical data to include in the model training phase. We do not include all of our historical data, which spans several months, because it becomes impractical due to memory limitations and the long training time. Also, the old data may become outdated. Figure 4 shows that the model needs at least one week of data to bootstrap and two weeks to reach a relatively satisfactory performance. Increasing the number of days has no significant effect. This phenomenon can be related to the weekly programming pattern of the OTT service. Thus, the performance of the model can be significantly improved with one complete data collection cycle and continues to improve up to about 14 days. Therefore, we trained our models on the last 14 days of data.

The training task typically took 30 minutes on our database and model training server (see Figure 1). Our model was retrained every night and then deployed to the TensorFlow serving server. Retraining the model allows it to adapt to new scenarios and distribution shifts from the training data that may occur in a real system.

### 3.4. Neural network structure

We use the Neural Network (NN) structure with 4 fully connected dense layers of 64 neurons each shown in Figure 6. The NN estimates, for a peer $p_1$, the throughput of future exchanges with a peer $p_2$ if selected as a neighbor. This estimate serves as the score that the ML policy gives to a potential neighbor, as discussed in Section 2.2.1. The inputs are indicated in light blue. The categorical variables are encoded in one hot sequence, including the geolocation / ISP, devices (for both $p_1$ and $p_2$), and channel tokens. Numerical throughput features (CDN throughput and past upload throughput of $p_2$) are combined with the encoded values and passed into four dense layers (64 units each) with ReLu activation functions (rectified linear unit). The output is the throughput estimation of the link between $p_2$ and $p_1$.
<figure><img src="image_9.png" /><figcaption>(a) Regression plot of # of evaluations versus # of CPU cores used. The fitted line reveals the linear relation between the number of neighbor evaluations and the CPU cores needed. This information is then used to estimate the CPU needed in production.</figcaption></figure>

<caption>(b) Number of viewers, of neighbor selection requests, estimated # CPU cores needed, and inference time.</caption>

Figure 7: Estimation of the CPU resources required by the TensorFlow server to handle the neighbor selection requests.

## 3.5. Model deployment

A key issue when deploying an ML model in production is its performance because a delayed neighbor search response will postpone the overlay construction, impairing the V2V ratio. Tensorflow Serving is often used to serve trained Tensorflow models. Thus, we are interested in estimating the resources needed for a real deployment.

The model is queried when a peer needs neighbors, i.e., when a new peer joins the system or has fewer than ten neighbors, e.g., because some of its neighbors have left. A peer is limited to request once every 10 seconds to avoid saturating the servers. Furthermore, when selecting the best neighbors, we do not evaluate all potential peers. The evaluation is limited to *N* potential neighbors, selected uniformly at random over all peers. Indeed, it is impractical to evaluate all possible candidates during a large-audience event with thousands of peers. Thus, *N* peer evaluations are done per neighbor request.

We tested the impact of the number of peer evaluations per second (=$N \times RPS$ with $RPS$ the number of requests per second) on the CPU usage of the Tensorflow server by simulation. We deployed our system and made the values of *N* and RPS vary. We plot the number of cores used by the server for the different loads in the top chart of Figure 7. We found a linear relationship between the number of evaluations and CPU usage. Therefore, with the simple linear regression model fitted to the data, we could estimate the number of cores needed *in production*, as shown in the bottom chart of Figure 7. We report statistics (number of users and number of requests) for a typical streaming event with a peak audience of almost 3800 simultaneous users. We observe that the number of neighbor requests per second is close to #users/10. It is explained by the high churn of live streaming systems, which makes that a peer loses at least one neighbor during most 10-second intervals. The inference time, i.e. the time for the model to propose the best neighbor for a peer, is shown in green. It varies between 2 and 4.5 ms, depending on the CPU load. So it does not cause any significant delay for users. Finally, the estimated CPU usage is shown in red. Two cores are sufficient to handle the peak load (1.6 cores) of about 3800 users, corresponding to about 360 RPS when $N = 100$. Thus, our model can be efficiently deployed with a single server using these parameter values.

# 4. Experimental results

## 4.1. Overall results

We carried out 8 A/B test experiment campaigns to compare the performances of the presented neighbor selection strategies. Table 2 provides an overview of their results. The metrics ending with a 0 (resp. 1) corresponds to Policy 0 (resp. 1). The *Imp* columns correspond to the improvement of Policy 1 over Policy 0.
<table><thead><tr><th rowspan="2">Policy0</th><th rowspan="2">Policy1</th><th colspan="3">Throughput (kbit/s)</th><th colspan="3">Delay (ms)</th><th colspan="3">Chunk Loss Rate (%)</th><th colspan="3">Quality Switches (#)</th></tr><tr><th>TP0</th><th>TP1</th><th>ImpTP</th><th>DL0</th><th>DL1</th><th>ImpDl</th><th>CLR0</th><th>CLR1</th><th>ImpCLR</th><th>Swt0</th><th>Swt1</th><th>ImpSwt</th></tr></thead><tbody><tr><td>Random</td><td>Geo</td><td>2 763.86</td><td>3 180.80</td><td>1.15</td><td>677.58</td><td>503.19</td><td>0.74</td><td>0.31</td><td>0.26</td><td>0.86</td><td>5.06</td><td>4.67</td><td>0.92</td></tr><tr><td rowspan="7">Geo</td><td>Geo-ISP</td><td>3 206.91</td><td>3 216.68</td><td>1.00</td><td>485.95</td><td>458.20</td><td>0.94</td><td>0.26</td><td>0.25</td><td>0.98</td><td>4.90</td><td>4.85</td><td>0.99</td></tr><tr><td>Geo-Distance</td><td>3 138.06</td><td>3 139.19</td><td>1.00</td><td>499.45</td><td>512.25</td><td>1.03</td><td>0.25</td><td>0.24</td><td>0.98</td><td>5.72</td><td>5.60</td><td>0.98</td></tr><tr><td>NN7-fs<sub>1</sub></td><td>3 143.39</td><td>3 228.37</td><td>1.03</td><td>530.68</td><td>520.85</td><td>0.98</td><td>0.29</td><td>0.25</td><td>0.88</td><td>4.93</td><td>4.58</td><td>0.93</td></tr><tr><td>NN14-fs<sub>1</sub></td><td>3 040.43</td><td>3 200.75</td><td>1.05</td><td>577.95</td><td>500.89</td><td>0.87</td><td>0.26</td><td>0.23</td><td>0.90</td><td>4.55</td><td>4.23</td><td>0.93</td></tr><tr><td>NN14-fs<sub>2</sub></td><td>2 957.57</td><td>3 195.89</td><td>1.08</td><td>591.09</td><td>482.97</td><td>0.82</td><td>0.27</td><td>0.22</td><td>0.83</td><td>4.94</td><td>4.55</td><td>0.92</td></tr><tr><td>NN14-fs<sub>3</sub></td><td>3 005.87</td><td>3 453.98</td><td>1.15</td><td>526.08</td><td>402.23</td><td>0.77</td><td>0.25</td><td>0.19</td><td>0.74</td><td><b>3.86</b></td><td><b>3.11</b></td><td><b>0.80</b></td></tr><tr><td>NN14-fs<sub>4</sub></td><td><b>2 993.50</b></td><td><b>3 508.40</b></td><td><b>1.17</b></td><td><b>489.94</b></td><td><b>361.93</b></td><td><b>0.74</b></td><td><b>0.25</b></td><td><b>0.16</b></td><td><b>0.63</b></td><td>3.63</td><td>3.01</td><td>0.83</td></tr></tbody></table>

<table><caption>Table 2: A/B Test Result Summary. The table lists the summarised results of eight experiments comparing the *Policy0* (1st column) and *Policy1* (2nd column). We compare seven different metrics between the two rival policies. For instance, *TP0* and *TP1* are the average throughputs using *Policy0* and *Policy1*, respectively. The *ImpTP* is the improvement of the throughput if we use *Policy1* instead of *Policy0*. We keep the same annotation for others metrics. The last column shows the number of sessions in the experiment. The best improvements over the *Geo* policy are marked in bold text.</caption><thead><tr><th rowspan="2">Policy0</th><th rowspan="2">Policy1</th><th colspan="3">Rebuffering (#)</th><th colspan="3">V2V Ratio (%)</th><th colspan="3">Average Chunk Size (MB)</th><th rowspan="2"># Session</th></tr><tr><th>Rebuf0</th><th>Rebuf1</th><th>ImpRebuf</th><th>V2VRatio0</th><th>V2VRatio1</th><th>ImpV2VR</th><th>AvgCS0</th><th>AvgCS1</th><th>ImpCS</th></tr></thead><tbody><tr><td>Random</td><td>Geo</td><td>2.35</td><td>2.07</td><td>0.88</td><td>0.37</td><td>0.38</td><td>1.05</td><td>0.98</td><td>0.99</td><td>1.01</td><td>174 680</td></tr><tr><td rowspan="7">Geo</td><td>Geo-ISP</td><td>2.31</td><td>2.23</td><td>0.97</td><td>0.40</td><td>0.39</td><td>0.99</td><td>0.98</td><td>0.99</td><td>1.00</td><td>132 402</td></tr><tr><td>Geo-Distance</td><td>2.49</td><td>2.47</td><td>1.00</td><td>0.40</td><td>0.40</td><td>1.00</td><td>1.05</td><td>1.05</td><td>1.00</td><td>112 356</td></tr><tr><td>NN7-fs<sub>1</sub></td><td>2.32</td><td>1.97</td><td>0.85</td><td>0.39</td><td>0.38</td><td>0.97</td><td>0.97</td><td>0.98</td><td>1.01</td><td>101 723</td></tr><tr><td>NN14-fs<sub>1</sub></td><td>2.15</td><td>1.74</td><td>0.81</td><td><b>0.37</b></td><td><b>0.38</b></td><td><b>1.02</b></td><td>0.98</td><td>0.99</td><td>1.01</td><td>156 141</td></tr><tr><td>NN14-fs<sub>2</sub></td><td>2.63</td><td>2.10</td><td>0.80</td><td>0.39</td><td>0.38</td><td>0.99</td><td>0.97</td><td>0.99</td><td>1.02</td><td>107 958</td></tr><tr><td>NN14-fs<sub>3</sub></td><td>2.52</td><td>1.88</td><td>0.75</td><td>0.40</td><td>0.38</td><td>0.96</td><td><b>0.97</b></td><td><b>1.02</b></td><td><b>1.05</b></td><td>126 088</td></tr><tr><td>NN14-fs<sub>4</sub></td><td><b>2.13</b></td><td><b>1.30</b></td><td><b>0.61</b></td><td>0.39</td><td>0.40</td><td>1.01</td><td>0.97</td><td>1.01</td><td>1.04</td><td>125 892</td></tr></tbody></table>

### 4.1.1. *Geo* significantly improves over *Random* neighbor selection

During the 7-day experiment of *Random* versus *Geo* (first row of Table 2), the average improvement throughput is 15%. All the other metrics are improved, e.g., the delay *DL* is reduced by 26% and the Chunk Loss Rate (CLR) by 14%. In terms of QoE, we observe 8% fewer quality switches, 12% less re-buffering, and a slightly larger chunk size. *Geo* neighbor selection, which constructs a locality-aware overlay, thus resulting in better V2V performance than a random mesh. The addition of further information like the ISP or an estimate of the physical distance to the original *Geo* model does not bring significant additional improvement. See Rows 2 and 3.

### 4.1.2. The locality-based methods perform similarly

Addition of further information like the ISP or an estimate of the physical distance to the original *Geo* model, does not bring significantly additional improvement in terms of any metrics (throughput, delay, CLR, etc.), see Rows 2 and 3 of Table 2. Also, note that the plain categorical models only using geographical and ISP information (*NN7-fs*<sub>1</sub> and *NN14-fs*<sub>1</sub>) have only slightly better performances than the *Geo* model (Rows 4 and 5): throughput is improved by 3 and 5%, respectively, delay by 2 and 13%, CLR by 12 and 10%.

### 4.1.3. Upload and download throughput information are keys for the NN models to improve over *Geo*

Using a neural network based on the geographical features per se is not enough to further enhance the quality of the distribution network, as the *Geo* over *NN7-fs*<sub>1</sub> experiment highlights (Rows 3 and 4 of Table 2). The best model is *NN14-fs*<sub>4</sub> which utilizes the geographical information, ISP, users' operating system, the channel, CDN throughput, and the upload throughput.
<figure><img src="image_10.png" /><figcaption>Figure 8: Improvement of different metrics compared to *Geo*. The $NN14-fs_4$ model outperforms all other policies in terms of QoE and QoS metrics.</figcaption></figure>

#### 4.1.4. 14 days is the sweet spot for training the models

As discussed in Section 3.3, the training period should at least be seven days. Increasing it leads to an improvement of the model until it reaches 14 days; then, the improvement becomes negligible. We thus select 14 days as the default training period for our NN models. We also tested 7 days for one model $NN7-fs_1$. We observe that the two weeks' data can improve the performance. However, the improvement is not considerable, confirming that longer training periods are unnecessary.

### 4.2. Detailed analysis

#### 4.2.1. Improving the throughput reduces the fraction of lost chunks

In a V2V system, the link quality directly relates to the success of chunk delivery. If the chunk takes too long to arrive (timeout), the peer falls back to the CDN server to preserve the QoE. The chunk loss rate (CLR) is thus an important metrics to optimize in a hybrid CDN/V2V system. A simple strategy is to use the estimated throughput between two arbitrary peers since the higher the throughput, the less time it takes to deliver a chunk, the lower the LR should be.

Figure 9a shows the improvement of throughput versus CLR. One point in the graph corresponds to one day with a specific type of experiment. We see a significant Pearson correlation value (-0.794). We observed this trend in every experiment we performed, including the random policy compared with Geo, Geo compared with the best NN, and Geo-ISP and Geo with Geo-distance model.

#### 4.2.2. The model trained on the throughput positively influences the E2E delay

In our experiments, the ML models focus on minimizing the mean square error between the throughput observed and its prediction. There exist alternative metrics, e.g., E2E delay, lost chunk that could have been used as targets. Nevertheless, our results demonstrate that using throughput as a target results into lower E2E delay, as shown in Figure 9b. Indeed, the higher improvements to the throughput has a large correlation with the improvement to the E2E delay, as can be seen when comparing Geo against Random and also Geo against $NN14-fs_4$.
<figure><img src="image_11.png" /><figcaption>Figure 9: Correlation analysis of the improvements of several metrics in the results of 4 A/B test campaigns corresponding to 4 colors. Each dot represents one day of experiment. Each line is the linear regression fitting the dots.</figcaption></figure>

### 4.2.3. The improvement in terms of delay improves the V2V ratio

We previously observed that optimizing the throughput leads to an improvement in terms of delay. Figure 9c further demonstrates the high correlation between the improvement of E2E delay and of the V2V ratio. A possible explanation would be that the peers will systematically announce the availability of chunks stored in the buffer (typically 10 – 30 chunks) depending on the size of the chunks. One chunk is identified by its CRC-16 hashed HLS URL taking up around 2x30 = 60 Bytes when the peer is fully loaded with chunks. The chunk map of a maximum of 60 Bytes needs to be sent periodically to one’s neighbors. However small this message is, it significantly impacts the V2V ratio. Because the sooner the neighbors receive the chunk availability information, the earlier they can start requesting the chunks in V2V mode, which effectively reduces the CDN load. Oppositely, if peers do not receive the chunk availability information, they will fetch chunks from CDN, reducing the V2V communications.

### 4.2.4. Importance of Geographic Information

<table><caption>Table 3: The numerical-only features in ML neighbor selection might result in more inter-country links</caption><thead><tr><th>Model</th><th># links</th><th>%Intra-Country</th><th>AvgTP (Kbit/s)</th><th>AvgDL (ms)</th><th>V2VRatio</th></tr></thead><tbody><tr><td>NN14-nums</td><td>10933</td><td>53.9%</td><td>3006.34</td><td>545.0</td><td>22.8%</td></tr><tr><td>Geo</td><td>18027</td><td>81.1%</td><td>3111.69</td><td>543.1</td><td>30.4%</td></tr><tr><td>NN14-fs<sub>4</sub></td><td>10135</td><td>84.4%</td><td>3779.59</td><td>345.0</td><td>35.5%</td></tr><tr><td>Geo</td><td>11432</td><td>87.8%</td><td>3179.17</td><td>508.5</td><td>36.5%</td></tr></tbody></table>

Our results indicate that the numerical features (past CDN and upload throughput) are the ones with the largest impact on the model, see Section 3. We tested a model using only these features and not the geographic information, namely *NN14-nums*. A synthesis of the obtained results is provided in Table 3. As expected, the proportion of intra-country links decreases from more than 80% to around 54%. Note that it does not affect too strongly the average throughput which only decreases by 3% from 3111 Kbit/s to 3006 Kbit/s and the average delay stays the same. Indeed, the *NN14-nums* model succeeds in optimizing for throughput. However, the V2V ratio drops by 25%. This means that NN14-nums often selects neighbors that are too far from other, leading to an inaccurate throughput prediction. Hence, the chunks are not delivered before the timeout, increasing the CLR.
# 5. Related Work

The P2P approach has been widely investigated as a candidate to offer video streaming. The overlay construction is one of the most discussed topics in this context. There exist different overlay classes, including tree-based, mesh-based, and hybrid networks. Pal et al. [34] uses the tree-based structure for lower latency, but it suffers from peer churn. The mesh-based network is the most resilient overlay w.r.t. load variation. However, it suffers from a higher latency, and the organization of the mesh is nontrivial. Therefore, much research is aimed at improving mesh-based overlays.

One option is to alter the tree-overlay with mesh components or vice versa. A DHT-aided mesh- overlay can enable the newcomers to be assigned such that the chunks are transmitted throughout a dynamic tree structure with top-down decreasing bandwidth Shen et al. [19]. ASTREAM Maheswari and Ramesh [18] integrates the location/upload capacity information to calculate a reputation score and build a hybrid overlay that uses the location/upload capacity information to form a tree-like overlay.

Another direction is to (re-)create the overlay from scratch because re-organization incurs much less overhead than adaption Beverly and Afergan [35]. When the mesh-based P2P networks were first proposed, a random peer selection of neighbors was the default approach to construct the overlay. More efficient methods have been proposed and proved to improve over a random peer selection. These approaches directly relate to our work.

## 5.1. Locality-awareness

The authors of Silverston et al. [20] demonstrate the importance of locality through a large-scale measurement of the P2P-TV system. Xu Zhang et al. [21] points out that locality awareness is not enough and introduces the concept of ISP-awareness to minimize the inter-domain / inter-ISP traffic. Zhao et al. [22] emphasized the necessity to keep a volume of inter-ISP traffic to achieve a “minimum cloud bandwidth.”

## 5.2. Latency-awareness

In Chakareski and Frossard [23], the authors propose a method to construct a delay-based overlay consisting of neighborhoods with similar latency. Their simulation results demonstrate improvements in terms of video quality and frame freezing rate over the random mesh. In Miguel et al. [24], the peers are classified into classes based on their contribution. The classes are then used to organize the peers, avoiding overloading the peers with the best connectivity.

## 5.3. Serviceability-awareness

Several works Maheswari and Ramesh [18], Lobb et al. [36], Biskupski et al. [37], Sheshjavani et al. [38] investigated the benefits of building diffusion overlays that consider the serviceability (upload capacity, age, location) of peers and move the better peers closer to the source.

## 5.4. Using Machine Learning

Lu et al. [39] discuss the challenges and opportunities of machine learning empowered content delivery. A line of works have explored such methods to improve hybrid streaming system. In particular, Zhang et al. [40] proposed Livesmart, a novel framework that facilitates a QoS-guaranteed cost-efficient approach for crowdsourced live streaming services using machine learning methods. The recent work Farahani et al. [25] proposes an online learning approach, RICHTER, to design an efficient Hybrid P2P-CDN Architecture.
As an extension to our previous work Ma et al. [41] which presents an offline data analysis and model testing, this work goes a few steps further by investigating practical issues for deploying a machine learning model in production: (1) feature selection (2) model tuning and, (3) model deployment. Our system uses a hybrid approach that simplifies the diffusion tree. We also consider an enriched set of features such as locality, ISP, device type, past CDN, and upload bandwidth. Several real-world A/B testing experiments demonstrate that an ML approach can improve over heuristic / deterministic neighbor selection strategies focusing only on a limited set of features.

# 6. Conclusion

The main objective of our work is to maximize the number of times the video chunks can be exchanged in a live video streaming session for a hybrid CDN/V2V architecture. We compared different neighbor selection strategies (e.g., random, Geo, ML-based) and different feature sets (e.g., including or not the upload throughput history) for an OTT service in production. A key point of our approach is to use A/B testing for comparing policies over long periods and for different channels whose audience varies over the day.

These large-scale experiments in the wild have enabled us to demonstrate the superiority of using an ML machine approach, suggesting that simple deterministic strategies such as Geo-based strategies are not enough. We further explain that the set of input features must be rich, including geographic information and the upload history of peers. Eventually, we show that focusing on the throughput as a metric to optimize several co-benefits for the QoS, i.e., the V2V channels (e.g., lower E2E delay, lower CLR) and QoE (higher quality, fewer quality switches).

In terms of future work, we intend to focus on the client-level operation since, currently, a peer selects at random among its neighbors one that offers the chunks it requires. More efficient strategies, e.g., keeping the history of the number of times a neighbor successfully delivers a video chunk, could improve efficiency.

# Acknowledgement

This work has been supported the French government National Research Agency (ANR) through the UCA JEDI (ANR-15-IDEX-01) and EUR DS4H (ANR-17-EURE-004), under the France 2030 programs "PEPR Networks of the Future" (ANR-22-PEFT-0002) and "PEPR Cloud" (ANR-23-PECL-0003), through the 3IA Cote d'Azur Investments in the project with the reference number ANR-23-IACL-0001, by SmartNet and LearnNet, and by the European Network of Excellence dAIEDGE under Grant Agreement No. 101120726.

# References

[1] Cisco, global 2021 forecast highlights - cisco.com, 2021. URL: https://www.cisco.com/c/dam/m/en_us/solutions/service-provider/vni-forecast-highlights/pdf/Global_2021_Forecast_Highlights.pdf.

[2] Akamai, Akamai cdn, 2022. URL: https://www.akamai.com.

[3] Amazon, Amazon CloudFront, 2022. URL: https://aws.amazon.com/cloudfront/.

[4] Azure, Microsoftazure cdn, 2022. URL: https://azure.microsoft.com/en-us/services/cdn/.

[5] Google, Cloud CDN, 2022. URL: https://cloud.google.com/cdn.
[6] B. Frank, I. Poese, Y. Lin, G. Smaragdakis, A. Feldmann, B. Maggs, J. Rake, S. Uhlig, R. Weber, Pushing CDN-ISP collaboration to the limit, ACM SIGCOMM Computer Communication Review 43 (2013) 34–44. URL: https://dl.acm.org/doi/10.1145/2500098.2500103. doi:10.1145/2500098.2500103.

[7] C. Huang, A. Wang, J. Li, K. W. Ross, Understanding hybrid CDN-p2p: why limelight needs its own red swoosh, in: ACM NOSSDAV, 2008. doi:10.1145/1496046.1496064.

[8] H. Yin, X. Liu, T. Zhan, V. Sekar, F. Qiu, C. Lin, H. Zhang, B. Li, Design and deployment of a hybrid CDN-p2p system for live video streaming: experiences with LiveSky, in: ACM MM, 2009. doi:10.1145/1631272.1631279.

[9] EasyBroadcast, EasyBroadcast end-to-end OTT streaming for broadcast, enterprise, and education, 2022. URL: https://easybroadcast.fr/.

[10] Xiangying Yang, G. de Veciana, Service capacity of peer to peer networks, in: IEEE INFOCOM 2004, volume 4, 2004, pp. 2242–2252. doi:10.1109/INFCOM.2004.1354647.

[11] S. Xie, B. Li, G. Y. Keung, X. Zhang, Coolstreaming: Design, theory, and practice, IEEE Transactions on Multimedia (2007). doi:10.1109/TMM.2007.907469.

[12] C. Wu, B. Li, S. Zhao, Exploring large-scale peer-to-peer live streaming topologies 4 (2008) 1–23. URL: https://dl.acm.org/doi/10.1145/1386109.1386112. doi:10.1145/1386109.1386112.

[13] Jiangchuan Liu, S. Rao, Bo Li, Hui Zhang, Opportunities and challenges of peer-to-peer internet video broadcast, Proceedings of the IEEE 96 (2008) 11–24. doi:10.1109/JPROC.2007.909921.

[14] D. Xu, S. S. Kulkarni, C. Rosenberg, H.-K. Chai, Analysis of a CDN-p2p hybrid architecture for cost-effective streaming media distribution, Multimedia Systems 11 (2006) 383–399. doi:10.1007/s00530-006-0015-3.

[15] M. Zhang, L. Zhao, Y. Tang, J.-G. Luo, S.-Q. Yang, Large-scale live media streaming over peer-to-peer networks through global internet, in: ACM P2PMMS, 2005. doi:10.1145/1099384.1099388.

[16] V. Pai, K. Kumar, K. Tamilmani, V. Sambamurthy, A. E. Mohr, Chainsaw: Eliminating trees from overlay multicast, in: Springer International Workshop on Peer-to-Peer Systems, 2005. doi:10.1007/11558989_12.

[17] N. Magharei, R. Rejaie, Prime: Peer-to-peer receiver-driven mesh-based streaming, IEEE/ACM Transactions on Networking (2009).

[18] B. U. Maheswari, T. K. Ramesh, An improved delay-resistant and reliable hybrid overlay for peer-to-peer video streaming in wired and wireless networks 6 (????) 56539–56550. URL: https://ieeexplore.ieee.org/document/8482115/. doi:10.1109/ACCESS.2018.2871932.

[19] H. Shen, Z. Li, J. Li, A DHT-aided chunk-driven overlay for scalable and efficient peer-to-peer live streaming 24 (2013) 2125–2137. doi:10.1109/TPDS.2012.302, conference Name: IEEE Transactions on Parallel and Distributed Systems.
[20] T. Silverston, L. Jakab, A. Cabellos-Aparicio, O. Fourmaux, K. Salamatian, K. Cho, Large-scale measurement experiments of p2p-TV systems. insights on fairness and locality 26 (2011) 327-338. URL: https://hal.archives-ouvertes.fr/hal-00648019. doi:10.1016/j.image.2011.01.007, publisher: Elsevier.

[21] Xu Zhang, Ning Wang, M. Howarth, A hybrid peer selection scheme for enhanced network and application performances, in: 2013 IEEE 10th Consumer Communications and Networking Conference (CCNC), IEEE, 2013, pp. 13-21. URL: http://ieeexplore.ieee.org/document/6488419/. doi:10.1109/CCNC.2013.6488419.

[22] J. Zhao, C. Wu, X. Lin, Locality-aware streaming in hybrid p2p-cloud CDN systems 8 (2015) 320-335. URL: https://doi.org/10.1007/s12083-013-0233-3. doi:10.1007/s12083-013-0233-3.

[23] J. Chakareski, P. Frossard, Delay-based overlay construction in p2p video broadcast, in: 2009 IEEE International Conference on Acoustics, Speech and Signal Processing, IEEE, 2009, pp. 1985-1988.

[24] E. C. Miguel, C. M. Silva, F. C. Coelho, I. F. S. Cunha, S. V. A. Campos, Construction and maintenance of p2p overlays for live streaming (2021). URL: https://doi.org/10.1007/s11042-021-10604-w. doi:10.1007/s11042-021-10604-w.

[25] R. Farahani, A. Bentaleb, E. Cetinkaya, C. Timmerer, R. Zimmermann, H. Hellwagner, Hybrid p2p-cdn architecture for live video streaming: An online learning approach, in: GLOBECOM 2022-2022 IEEE Global Communications Conference, IEEE, 2022, pp. 1911-1917.

[26] B. Li, D. Niu, Random network coding in peer-to-peer networks: From theory to practice 99 (2011) 513-523. doi:10.1109/JPROC.2010.2091930, conference Name: Proceedings of the IEEE.

[27] WebRTC 1.0: Real-time communication between browsers, ???? URL: https://www.w3.org/TR/weecrtc/.

[28] C. Olston, N. Fiedel, K. Gorovoy, J. Harmsen, L. Lao, F. Li, V. Rajashekhar, S. Ramesh, J. Soyke, TensorFlow-serving: Flexible, high-performance ML serving, arXiv:1712.06139 [cs] (2017). arXiv:1712.06139.

[29] D. B. Rubin, Statistics and causal inference: Comment: Which ifs have causal answers, Journal of the American Statistical Association (1986). doi:10.2307/2289065.

[30] A. Johnsson, B. Melander, M. Björkman, Bandwidth measurement in wireless networks, in: IFIP Annual Mediterranean Ad Hoc Networking Workshop, Springer, 2005, pp. 89-98.

[31] A. P. C. da Silva, E. Leonardi, M. Mellia, M. Meo, A bandwidth-aware scheduling strategy for p2p-tv systems, in: 2008 Eighth International Conference on Peer-to-Peer Computing, IEEE, 2008, pp. 279-288.

[32] C.-C. Wang, Y.-D. Lin, Cdnpatch: a cost-effective failover mechanism for hybrid cdn-p2p live streaming systems, International Journal of Communication Systems 29 (2016) 2517-2533.

[33] Feast: Feature store for machine learning, 2022. URL: https://feast.dev/.
[34] K. Pal, M. Govil, M. Ahmed, A new hybrid approach for overlay construction in p2p live streaming, in: 2015 International Conference on Advances in Computing, Communications and Informatics (ICACCI), 2015, pp. 431–437. doi:10.1109/ICACCI.2015.7275647.

[35] R. Beverly, M. Afergan, Machine learning for efficient neighbor selection in unstructured p2p networks (2007) 6.

[36] R. J. Lobb, A. P. Couto da Silva, E. Leonardi, M. Mellia, M. Meo, Adaptive overlay topology for mesh-based p2p-TV systems, in: Proceedings of the 18th international workshop on Network and operating systems support for digital audio and video - NOSSDAV '09, ACM Press, 2009, p. 31. URL: http://portal.acm.org/citation.cfm?doid=1542245.1542253. doi:10.1145/1542245.1542253.

[37] B. Biskupski, M. Schiely, P. Felber, R. Meier, Tree-based analysis of mesh overlays for peer-to-peer streaming, in: R. Meier, S. Terzis (Eds.), Distributed Applications and Interoperable Systems, volume 5053, Springer Berlin Heidelberg, 2008, pp. 126–139. URL: http://link.springer.com/10.1007/978-3-540-68642-2_11. doi:10.1007/978-3-540-68642-2_11, series Title: Lecture Notes in Computer Science.

[38] A. G. Sheshjavani, B. Akbari, H. R. Ghaeini, A free-riding resiliency incentive mechanism for VoD streaming over hybrid CDN-p2p networks, in: 2016 8th International Symposium on Telecommunications (IST), 2016, pp. 771–776. doi:10.1109/ISAD.2016.7881928.

[39] Z. Lu, K. Gai, Q. Duan, K.-K. R. Choo, J. Li, J. Wu, Y. Xu, Machine learning empowered content delivery: status, challenges, and opportunities, IEEE Network 34 (2020) 228–234.

[40] R.-X. Zhang, M. Ma, T. Huang, H. Pang, X. Yao, C. Wu, J. Liu, L. Sun, Livesmart: A guaranteed cost-minimum framework of viewer scheduling for crowdsourced live streaming, in: Proceedings of the 27th ACM International Conference on Multimedia, 2019, pp. 420–428.

[41] Z. Ma, S. Roubia, F. Giroire, G. Urvoy-Keller, When locality is not enough: Boosting peer selection of hybrid cdn-p2p live streaming systems using machine learning, in: Network Traffic Measurement and Analysis Conference (IFIP TMA 2021), 2021.