Vidéo a la demande en Peer-to-peer intégral

Vidéo a la demande en Peer-to-peer intégral
où l'on montre qu'il faut avoir un gros catalogue et bien s'en servir
Yacine Boufkhad, Fabien Mathieu, Fabien de Montgoler, Diego Perino et Laurent Viennot
Vidéo a la demande en Peer-to-peer intégral
1
2
1
Yacine Boufkhad , Fabien Mathieu , Fabien de Montgoler ,
2
1
Diego Perino , Laurent Viennot
(1) Projet ANR Aladdin & Équipe-projet INRIA GANG &
LIAFA (CNRS-Université Paris Diderot)
(2) Orange Labs
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
problem statement
Un modèle P2P pour la VoD
Protagonistes
I Une organisation (FAI) souhaitant proposer un service de vidéo
I Des client ADSL, possédant des @µ~Z∇
^-box
Hypothèses
I Les clients doivent regarder leur vidéo
on-demand : sans
I Bien sûr chacun demande ce qu'il veut, quand il veut
I Le
Catalogue est l'ensemble des vidéos proposées
délai
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
What it is not
Modèle à serveur
server
client
client
client
client
_
I Bande passante limitée et chère ¨
_
I Capacités de stockage limitées et chères ¨
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
What it is not
Un modèle P2P pour la VoD
Protagonistes
I Une organisation (FAI) souhaitant proposer un service de vidéo
I Des client ADSL, possédant des @µ~Z∇
^-box
ayant des
capacité de stockage (disque dur) et d'upload
Hypothèses
I Les clients doivent regarder leur vidéo
on-demand : sans
I Bien sûr chacun demande ce qu'il veut, quand il veut
I Le
Catalogue est l'ensemble des vidéos proposées
délai
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
What it is not
Problèmes connexes
Téléchargement simple
I
oine
: délai non borné.
I eMule, BitTorrent [Bram Cohen 2003],...
Multicast
I Sert à diuser du contenu
live
I Chacun regarde le même ux, au même point
I SplitStream [Castro et al. 2003], ZigZag [Tran et al. 2003]
PPLive [Hei et al 2006] Prexstream [Gai Viennot 2006]. . .
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
What it is
P2P suppléant un serveur
server
client
client
client
client
I Les capacités de relais des pairs sont utiliées pour aider la
une seule vidéo [Hei et al. 2006, Annapureddy
distribution d'
et al. 2007, Cheng et al. 2007, Huang et al. 2007, . . . ]
_
I Capacités de stockage du serveur toujours limitées et chères ¨
^
I Répartition de la charge pour une vidéo ¨
_
I mais étranglement du serveur si bcp de vidéos regardées ¨
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
What it is
P2P pur
server
client
I
client
client
client
plus de serveur Les données sont stockées sur les disques des
box [Push-to-Peer, Suh et al. 2007]
^
I Croissance sans problème du système ¨
^
I Répartition de la charge pour une vidéo ¨
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
What it is
P2P pur
server
client
I
client
client
client
plus de serveur Les données sont stockées sur les disques des
box [Push-to-Peer, Suh et al. 2007]
^
I Croissance sans problème du système ¨
^
I Répartition de la charge pour une vidéo ¨
I catalogue de taille constante _
¨
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
What it is
P2P pur
server
client
I
client
client
client
plus de serveur Les données sont stockées sur les disques des
box [Push-to-Peer, Suh et al. 2007]
^
I Croissance sans problème du système ¨
^
I Répartition de la charge pour une vidéo ¨
I catalogue de taille constante _
¨
^
^
^
I Notre but : faire grossir le catalogue ¨
¨
¨
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
Our goal
Notre but
I Étant donnés les paramètres physiques du système :
I Taille des disques des box
I Upload et download des box
I Taille et débit des vidéos stockées
I en supposant le
pire scénario
(implique que chacun regarde un
lm)
I et en garantissant la QoS
nous voulons maximiser la taille du catalogue.
O (n)
borne triviale.
Ω(n)
atteignable ?
Vidéo a la demande en Peer-to-peer intégral
VoD over P2P ?
Our goal
Plan
I Exposé du modèle deux-temps
I Un résultat théorique d'optimalité
I cas homogène
I cas général
I Des algorithmes pratiques
I Des simulations
Vidéo a la demande en Peer-to-peer intégral
Modèle
Un modèle en deux temps
Peut-on vraiment se passer du serveur ?
1- Déploiement
Un serveur stocke des données de vidéos dans les disques des box
(tâche de fond à débit lent, temps diéré)
2- Service
Quand un client veut regarder une vidée, il la télécharge depuis
certaines box en temps réel
Nous nous intéressons à
stocker les vidéos (phase 1, centralisé)
d'où télécharger les vidéos (phase 2, décentralisé, temps réel)
I où
I
Vidéo a la demande en Peer-to-peer intégral
Modèle
Stockage
Sous quel forme stocker les vidéos
Hypothèses
I
n
box
I
stockage identiques ou non
capacités d'émission identiques ou non
nombre constant de connections
I
m
I capacités de
I
vidéos visionnables
Stripping
I Diviser le ux video en
I
c
c
sous-ux
est justement le nombre de connections entrantes
I tolérence aux erreurs, répartition de la charge
Vidéo a la demande en Peer-to-peer intégral
Modèle
Stockage
Dans quelles boites stocker les stripes ?
Réponse : allocation aléatoire
I Chacune des
m
vidéos est coupée en
I Chaque stripe est copiée dans
I Permutation aléatoire des
mck
k
c
stripes
box
stripes
Justication
I On télécharge une stripe sans reconnection
I Pas d'hypothèse sur qui va télécherger quoi (futur inconnu)
→
symmétrie du problème
I Autre raison expliquée ensuite : propriété d'expander
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Dénition
Le modèle homogène
Propriétés des boites
I
I
I
n
utilisateurs =
n
box
stockage constant : d
upload constant u
vidéos / boîte
I nombre de connections entrantes constant
Propriétés des vidéos
I
m
vidéos disponibles
I ayant la même durée
I et le même débit
I coupées chacune en
c
stripes.
c
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Swarming
Le swarming (relais entre utilisateurs)
C'est quoi ?
La vidéo présentement regardée est mise en
cache. L'utilisateur
peut l'émettre vers d'autres
Pourquoi ?
Sans cela, taille de catalogue constante !
Que relayer ?
Tout morceau vu depuis un délai
t
Hypothèse de croissance régulière
Pendant ce temps
t
arrive au plus une proportion
(sinon, taille de catalogue constante aussi !)
µ
de requêtes
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Le théorème de Hall
Le théorème de Hall
Soit
Un
(X ∪ Y , E )
|X | = |Y |
|M | = |X | sans
un graphe biparti tq
couplage parfait est M ⊂ E
tq
entre arêtes
X
Y
Le théorème de Hall
un couplage parfait existe ssi
expansion)
(
∀S ⊂ Y |N (S )| ≥ |S |
incidences
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Le théorème de Hall
Le théorème de Hall
Soit
Un
(X ∪ Y , E )
|X | = |Y |
|M | = |X | sans
un graphe biparti tq
couplage parfait est M ⊂ E
tq
entre arêtes
X
Y
S
Le théorème de Hall
un couplage parfait existe ssi
expansion)
(
∀S ⊂ Y |N (S )| ≥ |S |
incidences
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Le théorème de Hall
Application du théorème de Hall
le biparti des requêtes
I
I
I
X = box
Y = {y1 ...yr } = requêtes = multi-ensemble de stripes
arêtes E tq N (yi ) ⊂ X = box pouvant satisfaire yi
assignation des connections : M ⊂ E tq
I
|M | = r
et toute requête
I toute box
x
X
b=2
Y
yi
touche au plus
touche une arête de
b
arêtes de
M
M
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Le théorème de Hall
Application du théorème de Hall
Théorème de Hall generalisé
Une assignation existe ssi
(1/b)-expansion
b
∀S ⊂ Y |N (S )| ≥ |Sb |
= nombre de sockets d'upload. Ici constant et
Modèle hétérogène : fonction
b(x )
de moyenne
c
b = c.
(cf infra)
X
b=2
Y
S
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Théorème principal
Alors, est-ce possible ?
Théorème
Une allocation par
pour
tout
permutation aléatoire est un 1/b-expander
multi-ensemble de requetes
I avec forte probabilité
I modèle homogène, pour l'instant
I il faut upload
I avec
c
>
download
(nombre de stripes) fonction de
de croissance max
I avec
O (log d )
µ
upload
download
copies de chaque stripe (où
et de la vitesse
d =taille
de disque)
Conséquence :
Une taille de catalogue de
(
Θ(n)
dn )
Ω( logd
vidéos diérentes est possible
lms est l'optimum. Atteint !)
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Théorème principal
Démonstration
Théorème
Une taille de catalogue de
dn )
Ω( logd
vidéos diérentes est possible
I Pas de reconnection : connecter les nouveaux seulement
I Obstruction : ens
S
de req tq.
|Upload (Box ayant S )| < |Sc |
I Si arrive, l'upload du swarm ne peut satisfaire la demande de dl
I Ratio
download / upload
I Espérance qu'il arrive
α>0
majoré par
≥1
µ/u
obstruction(s) :
fonction des paramètres
(d , u , µ...)
technique !
I Inégalité de Markov permet de conclure
O (1/nα )
avec
mais pas de
n.
Point
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Théorème principal
Les points techniques
Théorème
dn )
Ω( logd
Une taille de catalogue de
vidéos diérentes est possible
Les vraies valeurs
I
I
I
I
I
2
c > 2µu−−11 stripes
d0
k ≥ 5ν −1 log
log u 0 copies
1
ν = c +2µ1 2 −1 − uc
u 0 = c1 buc c
d 0 = max{d , u , exp(1)}
I et nalement
m=Ω
1
(u −1)2 log u +
2 1 dn
u3
µ2 log d 0
vidéos
Vidéo a la demande en Peer-to-peer intégral
Résultat théorique, cas homogène
Théorème principal
Plus de lms ou plus de qualité ?
u
Les vidéos ont débit v
P2P pur =⇒ v < u
Si v est grand...
I Les box ont upload
I
I
I
I ...la qualité est meilleure, mais...
I ...le catalogue est plus petit !
I
m→0
en
3
u
v −1
Vidéo a la demande en Peer-to-peer intégral
Résultat pour le cas hétérogène
Problème !
Hétérogénité : le problème
Toutes les box ne sont pas créées égales...
Deux sortes de box :
riches
(upload>seuil) et
Si trop de pauvres dans le swarm
→
pauvres
plus d'upload dispo !
Hypothèse d'homogénéité faible
Il y a problème si les riches ont un petit disque :
I Intuitivement, requêtes reçues
I Mais requêtes satisfaites
≤
'
stripes stockées
upload
Solution : imposer une minoration de
d /u
(idéalement
d /u = cste )
Vidéo a la demande en Peer-to-peer intégral
Résultat pour le cas hétérogène
Solution !
Hétérogénité : la solution
I Aecter à toute pauvre box
b
une box riche
I Réserver des slots upload pour
I Certaines stripes requises à
I
r (b)
b
b
chez
r (b)
r (b)
sont routées par
les émet donc à la place de
r (b)
b
swarming upload
r(b)
b
download
I Bien sûr certains slots d'upload de
r (b)
sont gâchés...
Vidéo a la demande en Peer-to-peer intégral
Résultat pour le cas hétérogène
Conclusion de la partie théorique
Conclusion de la partie théorique
I Nous avons montré l'existence d'un seuil :
I Si
upload
download
<1
la taille de catalogue est constante
I Si
upload
download
>1
le catalogue passe à l'échelle : taille
I L'algorithme d'allocation : simplement aléatoire !
I Boites homogènes ou hétérogènes (mais à
I Tous scénarios de requête (pire cas)
upload
disque
→
m = Ω(n)
robustesse
majoré)
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Trois algorithmes de connection
1 Connection simple (S)
Le visonneur se connecte à l'une des
k
boîtes stockant son lm.
Quand plus d'émission dispo dans aucune des
k
boîtes : échec !
2 Connection avec cache et relais (C)
Chaque visonneur a un
cache de la vidéo regardée.
Un nouveau visonneur se connecte a un des
ou à un des l
k
pairs stockant le lm
pairs le visonnant.
Quand plus d'émission dispo dans aucune des
k +l
boîtes : échec !
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Trois algorithmes de connection
3 Connection dynamique avec relais (D)
Un pair serveur peut déconnecter un pair client (qui devra se
reconnecter)
Règle de priorité serveur :
I Préférer le relais au stockage : déconnecter si besoin
I Mais réserver une connection de stockage !
Règle de priorité client :
I Requerir seulement des relais (connus par
tracker)
I Cependant pour un swarm petit, requêtes faites dans
relais+stockage
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Autre idée
Question :
On se place dans un scénario de popularités diérentes. Chaque
lm a une popularité connue.
Vaut-il mieux pré-charger les lms selon la popularité, on tous
autant et utiliser le cache ?
Pré-chargement suivant la popularité
I Chaque vidéo est découpée en
c
stripes (pour telechargement
simultané)
I Chaque stripe est pré-chargéee max(1,α.Popu(lm)) fois sur
des boîtes
aléatoires
I La taille du catalogue est toujours
constante)
O (n)
(réplication moyenne
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Hypothèse d'occurrence des requêtes
Requêtes poissonniennes
Ensuite, les boîte demandent à voir une vidéo. Le début du
visionnage suit une loi de Poisson. Plusieurs scénarios :
1. Demandes uniformes
2. Demandes suivant une popularité en loi de Zipf
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Simulations
Hypothèses
1000 peers, 25 lms par boîte.
Arrivées réalistes avec burst max 27/5 sec, loi de Poisson modié,
moyenne 17/5 sec
Répartition réaliste en Zipf Law des requêtes de paramètre 0.4
Quelles courbes ?
Simple, Cache, Dynanique
2 allocations lms sur boîtes : Equiréparti ou Power law
I 3 algorithmes de requêtes :
I
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Simulation : insatisfaction en fonction de la réplication
0.8
SE
CE
DE
SP20
CP20
0.7
0.6
Failure ratio
0.5
0.4
0.3
0.2
0.1
0
0
2
4
6
8
10
12
Number of copies
14
16
18
20
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Simulations
Quelles courbes ?
I 3 algorithmes de requêtes :
Simple, Cache, Dynanique
Equiréparti ou Power law
I 2 allocations lms sur boîtes :
Quel résultat ?
I Abscisse : un paramètre varie
I Ordonnée : on lit les échecs ou la taille du catalogue
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Quelle valeur pour l'upload ?
0.5
0.45
0.4
Failure ratio
0.35
0.3
SE
0.25
CE
DE
0.2
SP20
CP20
0.15
0.1
0.05
0
1
1.05
1.1
1.15
1.2
1.25
1.3
Upload capacity
1.35
1.4
1.45
1.5
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Quel catalogue ? (requêtes suivant popularité réaliste)
4
2.5
x 10
SE
CE
2
DE
SP20
# of videos
CP20
1.5
1
0.5
0
1
1.05
1.1
1.15
1.2
1.25
1.3
upload capacity
1.35
1.4
1.45
1.5
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Quel catalogue ? Scénario BlockBuster : 50% req. sur le
même lm
7000
SE
CE
6000
DE
SP20
5000
Number of videos
CP20
4000
3000
2000
1000
0
1
1.05
1.1
1.15
1.2
1.25
1.3
Upload capacity
1.35
1.4
1.45
1.5
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Insatisfaction
15000
SE
CE
DE
SP20
Number of videos
10000
5000
0
10
6
4
1
0.6
Failure percentage
0.4
0.1
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Inuence du tracker (nombre de peers testés au max)
6000
SE
CE
5000
DE
SP20
CP20
Number of videos
4000
3000
2000
1000
0
5
10
15
20
25
30
List size
35
40
45
50
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Erreurs sur Zipf Law
4
2.5
x 10
SP
SP10
SP20
SPr
2
CP
number of videos
CP10
CP20
1.5
CPr
1
0.5
0
1
1.05
1.1
1.15
1.2
1.25
1.3
upload capacity
1.35
1.4
1.45
1.5
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
Simulations
Paramètres et leurs valeurs par défaut du simulateur
n
m
d
u
c
x
Nombre de boites (1000)
Nombre de vidéos.
nd = km
(5 ou variable)
Nombre de lms par boîte (25)
upload d'une boîte (1.2 débit video)
Nombre de connections entrantes = nombre de stripes (10)
Pairs demandés au tracker (30)
Vidéo a la demande en Peer-to-peer intégral
Algorithmes réalistes de connection
conclusion
Conclusion des expérimentations
Le relais avec connection dynamique est robuste
Un pair trouvera à se connecter dans le swarm si réplication
logarithmique (théorème) voire constante (simulations)
La réplication par popularité sans relais est fragile
La moindre erreur sur la réplication est lourde
Reconnection dynamique ?
Utile sur les gros swarms !
Vidéo a la demande en Peer-to-peer intégral
publications
publications
Boufkhad, Mathieu, Montgoler, Perino, Viennot :
I
Achievable Catalog Size in Peer-to-Peer Video-on-Demand
Systems
IPTPS 2008, 7th International Workshop on Peer-to-Peer
Systems, Toronto
I
An upload bandwidth threshold for peer-to-peer
Video-on-Demand scalability.
IPDPS 2009, IEEE International Parallel & Distributed
Processing Symposium, Rome
I
Fine Tuning of a Distributed Video-on-Demand System
ICCCN 2009, 18th International Conference on Computer
Communications and Networks, San Francisco