Abeni, L.

Bakay, A.

Biazzini, M.

Birke, Robert Rene' Maria

Kiraly, C.

Leonardi, Emilio

Lo Cigno, R.

Mellia, Marco

Niccolini, S.

Seedorf, J.

Szemethy, T.

Tropea, G.

English

L. Abeni

A. Bakay

M. Biazzini

R. Birke

E. Leonardi

R. Lo Cigno

C. Kiraly

M. Mellia

S. Niccolini

J. Seedorf

T. Szemethy

G. Tropea

Crossref

Network Friendly P2P-TV: The Napa-Wine Approach

BIRKE, ROBERT RENE' MARIA

LEONARDI, Emilio

MELLIA, Marco

PORTO@iris (Publications Open Repository TOrino - Politecnico di Torino)

03 August 2020POLITECNICO DI TORINORepository ISTITUZIONALENetwork Friendly P2P-TV: The Napa-Wine Approach / L. Abeni; A. Bakay; M. Biazzini; R. Birke; E. Leonardi; R. LoCigno; C. Kiraly; M. Mellia; S. Niccolini; J. Seedorf; T. Szemethy; G. Tropea. - STAMPA. - (2010), pp. 1-2. ((Interventopresentato al convegno Peer-to-Peer Computing (P2P), 2010 IEEE Tenth International Conference on tenutosi a Delft,Netherlands nel August 2010.OriginalNetwork Friendly P2P-TV: The Napa-Wine ApproachPublisher:PublishedDOI:10.1109/P2P.2010.5569983Terms of use:openAccessPublisher copyright(Article begins on next page)This article is made available under terms and conditions as specified in the  corresponding bibliographic description inthe repositoryAvailability:This version is available at: 11583/2375520 since:IEEENetwork Friendly P2P-TV: The Napa-Wine ApproachL. Abeni1, ´A. Bakay4, M. Biazzini1, R. Birke2, E. Leonardi2, R. Lo Cigno1, C. Kiraly1, M. Mellia2,S. Niccolini3, J. Seedorf3, T. Szemethy4, G. Tropea51University of Trento, Italy; 2Politecnico di Torino, Italy; 3NEC Laboratories Europe, Germany;4Netvisor Ltd, Hungary; 5LightComm s.r.l, ItalyI. BACKGROUND & SCENARIOP2P-TV systems have become part of the Internet land-scape1. The architecture of these (normally proprietary) appli-cations is generally receiver-driven, in that receivers activelysearch for suitable peers to download from, trying to maximizetheir performance. This results in very aggressive applicationsthat generate huge and non optimized traffic loads.Fig. 1. Logical architecture of a P2P live streaming system interacting withan ALTO serverThe Napa-Wine EU project2 proposes an architecture whereP2P-TV clients exploit network measures to reduce theirnetwork footprint and, if available, exploit ALTO-like servicesto optimize topology and performance, and to minimize theoverall network load. ALTO3 is a proposal for supporting theinteraction between network operators and P2P applications,whose goal is providing applications with enough informationon the network structure to enable the optimization of theoverlay topology and the content dissemination, while mini-mizing network costs. Fig. 1 pictorially represents the logicalstructure of P2P Live Streaming applications using ALTO foroptimized peer selection. Each peer, when discovers new peersto update its neighborhood, sends the list of these candidatespeers to an ALTO server, which returns either a sorted list ofthe candidates, or the same list with some metrics associated.II. THE NAPA-WINE CLIENTFig. 2 presents the functional architecture of a Napa-WineP2P-TV client, which is based on chunkization of the mediaThis work is supported by the European Commission through the NAPA-WINE Project (Network-Aware P2P-TV Application over Wise Network –www.napa-wine.eu), ICT Call 1 FP7-ICT-2007-1, 1.5 Networked Media, grantNo. 2144121See for instance http://www.pplive.com, http://www.soapcast.com, http://www.tvants.com, and many others.2See http://www.napa-wine.eu for details3“Application-Layer Traffic Optimization (ALTO) Problem Statement,”IETF, RFC 5693, Oct. 2009. Topology ManagementMessaging Layer (ML)Monitoring LayerApplication LayerChunk TradingUDP/TCP/IPFig. 2. The functional architecture of a Napa-Wine P2P-TV client.and swarming on a generic mesh overlay. The client is basedon generic libraries we developed, and is organized in differentmodules, which are briefly outlined in the following.User Layer. It is the module in charge of ingesting andrendering the media. It does support different encoding, butmost of all it takes care of smart chunkization of the stream,so that priority diffusion can be implemented by schedulers.Topology Management & ALTO Interaction. Building theoverlay for a real-time P2P application is one of the mostcritical tasks. This module takes care of optimizing the overlaytaking into account both application-level performance andnetwork-level costs, also interacting with an ALTO server toobtain information that cannot be accessed at the applicationlevel (e.g., link costs).Chunk Trading. The exchange of chunks on the overlayrequires both signaling capabilities (e.g., to exchange buffermaps) and scheduling capabilities to optimize the diffusionof chunks. On the one hand, this means careful selection ofchunks so that they diffuse evenly and, on the other hand,it means selection of peers based on network-level metricsto meet performance goals while minimizing the networkfootprint.Monitoring Layer. Metrics like the RTT, the number ofhops from other peers, the available bandwidth, etc. requiresnetwork-level measures, which are implemented in this mod-ule. Some metrics can be retrieved from an external repositoryinstead of measured locally.Messaging Layer. An abstraction of the networking interfaceis provided by the ML, so that other modules do not have totake care of detailed networking functions like NAT traver-sal, shaping (if required), peer naming, chunk and messagesegmentation and reassembly, etc.The Topology Management and Chunk Trading are im-plemented on top of a set of generic libraries (GRAPES –Generic Resource Aware P2P Environment for Streaming)which provide all the basic functionalities needed for peersampling, for chunk scheduling, for exchanging buffermapsand chunk ID sets, for sending and receiving chunks, etc. The978-1-4244-7141-6/10/$26.00 ©2010 IEEEThis full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE P2P 2010 proceedings.Fig. 3. Real-time visualization of the overlay structure and swarm statusGRAPES libraries only depend on some basic functionalitiesfor sending and receiving messages, and the Messaging Layerdescribed above has been used for this purpose. Programsbased on GRAPES just need to implement some basic logicgluing the libraries’ functionalities together (this is generallyimplemented as a simple control loop receiving messages fromthe network and passing them to the libraries).III. DEMONSTRATIONS & MEASUREMENTSThe goal of this demo is to show the impact of variousP2P streaming options and the efficiency of the Napa-Wineapproach (compared to more traditional approaches) by run-ning real streaming clients in realistic conditions. To makethis comparison possible, the software developed in Napa-Wine is highly modular and configurable, allowing the userto test different topology management and chunk tradingtechniques developed within the Napa-Wine project, as well asto configure it to mimic other chunk/peer selection strategiesknown from literature. The Napa-Wine P2P-TV clients (withdifferent dialects and versions, testing the impact of differentpolicies and architectures) are already running over the Internetin about 100 physical nodes hosted by the project partners4,and our demonstration reproduces the most significant resultsachieved through these tests. To this end, some live streamsare distributed over the Internet. TV sources are DVB chan-nels transcoded directly from standard terrestrial and satellitedistribution systems, and the video quality can be selected torun experiments with different bitrates and frame sizes (oneof such possibilities is to distribute the DVB stream withouttranscoding).Since large scale, distributed experiments over the Internetare complex, and measures collection is a challenge in itself,we developed an ad-hoc repository for the collection of dataand the visualization of the system properties and measures.4Each physical node can host more than one logical peer, so that large scaleexperiments can be run easilyFig. 4. Example of visualizing the effect of ALTO guidance on the overlaytopologyFig. 3 shows example screenshots (red connections are suffer-ing from chunk losses). Measured quantities can be sampled atdifferent rates; they include the swarm topology, traffic volumebetween peers, chunks missing at each peer, packet losses atthe peers’ network interface, etc. In addition, all measurementsfrom the Monitoring Layer can also be pushed to the repositoryand displayed there. During the demo, both current measuresand data stored in the repository will be presented, explained,and commented, showing the performance of different P2Pstreaming algorithms and solutions.Given the configurability of Napa-Wine software, ALTO-guidance and different ALTO peer selection strategies can beselected live during the demo, and the effects can be evaluatedwith the Swarm Visualizer from the repository. For instance,Fig. 4 shows the resulting overlay topology in case A) ofcompletely randomly chosen peers, and B) - D) when peerselection is based on various ALTO strategies. In addition,the demo will display the resulting network layer costs for agiven topology, demonstrating the extent of backbone trafficcost reduction with ALTO strategies.Finally, the demo will also give insight into the behaviorof the peers and the underlying GRAPES libraries, as afunction of the selected chunk trading logic and protocol,network conditions, activated network measurements from theMonitoring Layer, and the availability of external informationsources (ALTO). Fig. 5 shows an example of these peersinsights, where the chunk buffer of one peer can be observedevolving at run-time while chunks are exchanged.Fig. 5. Real-time insight into peer statusThis full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE P2P 2010 proceedings.

PORTO Publications Open Repository TOrino

Network Friendly P2P-TV: The Napa-Wine Approach
L. Abeni1, ´A. Bakay4, M. Biazzini1, R. Birke2, E. Leonardi2, R. Lo Cigno1, C. Kiraly1, M. Mellia2,
S. Niccolini3, J. Seedorf3, T. Szemethy4, G. Tropea5
1University of Trento, Italy; 2Politecnico di Torino, Italy; 3NEC Laboratories Europe, Germany;
4Netvisor Ltd, Hungary; 5LightComm s.r.l, Italy
I. BACKGROUND & SCENARIO
P2P-TV systems have become part of the Internet land-
scape1. The architecture of these (normally proprietary) appli-
cations is generally receiver-driven, in that receivers actively
search for suitable peers to download from, trying to maximize
their performance. This results in very aggressive applications
that generate huge and non optimized traffic loads.
Fig. 1. Logical architecture of a P2P live streaming system interacting with
an ALTO server
The Napa-Wine EU project2 proposes an architecture where
P2P-TV clients exploit network measures to reduce their
network footprint and, if available, exploit ALTO-like services
to optimize topology and performance, and to minimize the
overall network load. ALTO3 is a proposal for supporting the
interaction between network operators and P2P applications,
whose goal is providing applications with enough information
on the network structure to enable the optimization of the
overlay topology and the content dissemination, while mini-
mizing network costs. Fig. 1 pictorially represents the logical
structure of P2P Live Streaming applications using ALTO for
optimized peer selection. Each peer, when discovers new peers
to update its neighborhood, sends the list of these candidates
peers to an ALTO server, which returns either a sorted list of
the candidates, or the same list with some metrics associated.
II. THE NAPA-WINE CLIENT
Fig. 2 presents the functional architecture of a Napa-Wine
P2P-TV client, which is based on chunkization of the media
This work is supported by the European Commission through the NAPA-
WINE Project (Network-Aware P2P-TV Application over Wise Network –
www.napa-wine.eu), ICT Call 1 FP7-ICT-2007-1, 1.5 Networked Media, grant
No. 214412
1See for instance http://www.pplive.com, http://www.soapcast.com, http://
www.tvants.com, and many others.
2See http://www.napa-wine.eu for details
3
“Application-Layer Traffic Optimization (ALTO) Problem Statement,”
IETF, RFC 5693, Oct. 2009.
 
Topology Management
Messaging Layer (ML)
Monitoring Layer
Application Layer
Chunk Trading
UDP/TCP/IP
Fig. 2. The functional architecture of a Napa-Wine P2P-TV client.
and swarming on a generic mesh overlay. The client is based
on generic libraries we developed, and is organized in different
modules, which are briefly outlined in the following.
User Layer. It is the module in charge of ingesting and
rendering the media. It does support different encoding, but
most of all it takes care of smart chunkization of the stream,
so that priority diffusion can be implemented by schedulers.
Topology Management & ALTO Interaction. Building the
overlay for a real-time P2P application is one of the most
critical tasks. This module takes care of optimizing the overlay
taking into account both application-level performance and
network-level costs, also interacting with an ALTO server to
obtain information that cannot be accessed at the application
level (e.g., link costs).
Chunk Trading. The exchange of chunks on the overlay
requires both signaling capabilities (e.g., to exchange buffer
maps) and scheduling capabilities to optimize the diffusion
of chunks. On the one hand, this means careful selection of
chunks so that they diffuse evenly and, on the other hand,
it means selection of peers based on network-level metrics
to meet performance goals while minimizing the network
footprint.
Monitoring Layer. Metrics like the RTT, the number of
hops from other peers, the available bandwidth, etc. requires
network-level measures, which are implemented in this mod-
ule. Some metrics can be retrieved from an external repository
instead of measured locally.
Messaging Layer. An abstraction of the networking interface
is provided by the ML, so that other modules do not have to
take care of detailed networking functions like NAT traver-
sal, shaping (if required), peer naming, chunk and message
segmentation and reassembly, etc.
The Topology Management and Chunk Trading are im-
plemented on top of a set of generic libraries (GRAPES –
Generic Resource Aware P2P Environment for Streaming)
which provide all the basic functionalities needed for peer
sampling, for chunk scheduling, for exchanging buffermaps
and chunk ID sets, for sending and receiving chunks, etc. The
978-1-4244-7141-6/10/$26.00 ©2010 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE P2P 2010 proceedings.
Fig. 3. Real-time visualization of the overlay structure and swarm status
GRAPES libraries only depend on some basic functionalities
for sending and receiving messages, and the Messaging Layer
described above has been used for this purpose. Programs
based on GRAPES just need to implement some basic logic
gluing the libraries’ functionalities together (this is generally
implemented as a simple control loop receiving messages from
the network and passing them to the libraries).
III. DEMONSTRATIONS & MEASUREMENTS
The goal of this demo is to show the impact of various
P2P streaming options and the efficiency of the Napa-Wine
approach (compared to more traditional approaches) by run-
ning real streaming clients in realistic conditions. To make
this comparison possible, the software developed in Napa-
Wine is highly modular and configurable, allowing the user
to test different topology management and chunk trading
techniques developed within the Napa-Wine project, as well as
to configure it to mimic other chunk/peer selection strategies
known from literature. The Napa-Wine P2P-TV clients (with
different dialects and versions, testing the impact of different
policies and architectures) are already running over the Internet
in about 100 physical nodes hosted by the project partners4,
and our demonstration reproduces the most significant results
achieved through these tests. To this end, some live streams
are distributed over the Internet. TV sources are DVB chan-
nels transcoded directly from standard terrestrial and satellite
distribution systems, and the video quality can be selected to
run experiments with different bitrates and frame sizes (one
of such possibilities is to distribute the DVB stream without
transcoding).
Since large scale, distributed experiments over the Internet
are complex, and measures collection is a challenge in itself,
we developed an ad-hoc repository for the collection of data
and the visualization of the system properties and measures.
4Each physical node can host more than one logical peer, so that large scale
experiments can be run easily
Fig. 4. Example of visualizing the effect of ALTO guidance on the overlay
topology
Fig. 3 shows example screenshots (red connections are suffer-
ing from chunk losses). Measured quantities can be sampled at
different rates; they include the swarm topology, traffic volume
between peers, chunks missing at each peer, packet losses at
the peers’ network interface, etc. In addition, all measurements
from the Monitoring Layer can also be pushed to the repository
and displayed there. During the demo, both current measures
and data stored in the repository will be presented, explained,
and commented, showing the performance of different P2P
streaming algorithms and solutions.
Given the configurability of Napa-Wine software, ALTO-
guidance and different ALTO peer selection strategies can be
selected live during the demo, and the effects can be evaluated
with the Swarm Visualizer from the repository. For instance,
Fig. 4 shows the resulting overlay topology in case A) of
completely randomly chosen peers, and B) - D) when peer
selection is based on various ALTO strategies. In addition,
the demo will display the resulting network layer costs for a
given topology, demonstrating the extent of backbone traffic
cost reduction with ALTO strategies.
Finally, the demo will also give insight into the behavior
of the peers and the underlying GRAPES libraries, as a
function of the selected chunk trading logic and protocol,
network conditions, activated network measurements from the
Monitoring Layer, and the availability of external information
sources (ALTO). Fig. 5 shows an example of these peers
insights, where the chunk buffer of one peer can be observed
evolving at run-time while chunks are exchanged.
Fig. 5. Real-time insight into peer status
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE P2P 2010 proceedings.


Network Friendly P2P-TV: The Napa-Wine Approach

Abstract

Similar works

Full text

Available Versions

Crossref

PORTO@iris (Publications Open Repository TOrino - Politecnico di Torino)

PORTO Publications Open Repository TOrino

Archivio istituzionale della ricerca - Università di Brescia