\include{parameters}
\usetheme{AFNIC}
\usepackage[french]{babel}
\usepackage[latin1]{inputenc}
\usepackage{bortzmeyer-utils}

\title{Sélectionner le meilleur pair}
\author{Stéphane Bortzmeyer\\AFNIC\\\texttt{bortzmeyer@nic.fr}}
\date{29 novembre 2010}

%\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex} 
% \setlength{\parskip}{15pt} 
\setlength{\parskip}{15pt plus 10pt minus 10pt} 

\begin{document}

\maketitle

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}
\frametitle{Le problème}

\begin{block}
{Je veux récupérer un gros fichier (mettons une image d'installation
d'un logiciel) en pair-à-pair.}
{\only<2->{Le système P2P que j'utilise (par exemple BitTorrent) trouve que
1 000 pairs potentiels (l'\emph{essaim}) ont ce fichier. Lequel
utiliser ? Certains sont chez le même FAI que moi, d'autres à l'autre
bout du monde. Et j'ai juste une liste d'adresses IP.}}
\end{block}
\end{frame}
        
\begin{frame}
\frametitle{Petit détour : comment on trouve la liste des pairs} 
Elle peut être obtenue par un serveur central, le \foreign{tracker}.

Ou bien dans le DNS.

Ou encore en pair-à-pair, sur une DHT.

Dans le premier cas, le serveur aura peut-être déjà fait un tri.
\end{frame}

\begin{frame}
\frametitle{Le problème, en un dessin}
\includegraphics[scale=0.47]{probleme.pdf}
\end{frame}

\begin{frame}
\frametitle{Les deux approches pour trier}
\begin{enumerate}
\item<2->L'application P2P peut mesurer elle-même la qualité des
pairs et en déduire le meilleur.
\item<3->Ou bien elle peut demander à un serveur spécialisé.\only<3-5>{ Deux sous-cas :
\begin{enumerate}
\item<4->Le serveur donne une « carte » du réseau et l'application P2P
en
déduit le pair le plus « proche ».
\item<5->Le client donne la liste des pairs potentiels et le serveur
lui indique les meilleurs.
\end{enumerate}
}
\end{enumerate}
\only<6->{Pour une comparaison des deux approches, et une revue de la
littérature, RFC 6029 \url{http://www.bortzmeyer.org/6029.html}}
\end{frame}

\begin{frame}
\frametitle{Mesurer soi-même}
Quelques questions préalables :
\begin{enumerate}
\item<1-> Mesurer quoi : distance géographique, \foreign{AS path}, latence, taux de pertes ou débit ?\only<1>{ Ce dernier ne peut se mesurer
qu'a posteriori.}
\item<2-> Mesurer comment : ICMP (\computer{ping}) n'est pas forcément
représentatif du trafic réel.\only<2>{ Mesures actives
(\computer{ping}) ou
passives (transférer et voir le résultat) ? Un GPS ou un client BGP dans chaque pair ?}
\item<3-> Mesurer qui : directement les pairs ?\only<3>{ Mauvaise \foreign{scalability} : on peut mesurer trois pairs
potentiels mais pas 10 000. Il vaut mieux utiliser des \emph{systèmes
de coordonnées} ou bien des mesures de distance hiérarchiques.}
\end{enumerate}
\end{frame}

\begin{frame}[fragile]
\frametitle{Systèmes de coordonnées Internet}
\begin{enumerate}
\item<2->On définit N \emph{amers}, des machines toujours
(bien) connectées que tout le monde peut voir,
\item<3->L'application mesure une « distance » (par exemple un RTT) à
chaque amer,
\item<4->Elle peut alors calculer sa position dans un espace à N
dimensions,
\item<5->Lorsqu'on récupère la liste des pairs, on récupère aussi
leurs positions. Calculer la distance à chaque pair devient trivial. 
\end{enumerate}
\end{frame}

\begin{frame}
\frametitle{Systèmes de coordonnées Internet, dessin}
\includegraphics[scale=0.47]{ics.pdf}
\end{frame}

\begin{frame}
\frametitle{Avantages des systèmes de coordonnées}
\only<1->{Le temps de mesure est proportionnel au nombre d'amers, pas
au nombre de pairs.}
\only<2->{Mis en \oe{}uvre, par exemple, dans
Vivaldi. \url{http://www.bortzmeyer.org/internet-coordinates.html}}
\end{frame}

\begin{frame}
\frametitle{Mesures de distance hiérarchiques}
Autre solution pour mesurer, avoir un
système \emph{hiérarchique}. Par exemple, Meridian repose sur un
système de pairs déjà connus (et donc de distance connue) :
\begin{enumerate}
\item<2->Les pairs connus sont regroupés en anneaux
concentriques, par ordre de distance. 
\item<3->Pour un pair inconnu, on demande aux pairs connus, qui
redirigent vers une machine plus proche.
\item<4->Jusqu'à ce qu'on arrive suffisamment proche.
\end{enumerate}
\only<5->{Zooms successifs, pas besoin
d'amers. \url{http://www.bortzmeyer.org/meridian.html}}
\end{frame}

\begin{frame}
\frametitle{Mesurer soi-même, les limites}
\begin{enumerate}
\item L'application P2P ne peut pas trouver seule qu'un lien est un
transit payant ou un \foreign{peering} gratuit. 
\item<2-> D'une manière générale, elle ne peut pas trouver seule quelles
sont les préférences du FAI.
\end{enumerate}
\end{frame}

\begin{frame}
\frametitle{Demander à un serveur}
Au lieu de mesurer soi-même, on demande à un serveur. Ce serveur aura
pu avoir l'info :
\begin{enumerate}
\item<2-> Par les techniques de mesures présentées plus haut,
\item<3-> Par une configuration manuelle, typiquement par le FAI.
\end{enumerate}
\only<4->{ Il va falloir définir un protocole normalisé pour interroger ce serveur.}
\end{frame}

\begin{frame}
\frametitle{Faire confiance ?}

Intérêt du FAI : utiliser les liens de \foreign{peerings} gratuits,
même s'ils sont surchargés.

Intérêt de 
l'utilisateur : télécharger le plus vite possible. 

\begin{block}{Il peut donc y avoir conflit.}
{C'est un problème fréquent en allocation de ressources.}
\end{block}

L'utilisation de ce système doit rester facultative (comme cela, les
FAI seront motivés pour le rendre efficace pour les utilisateurs).

\end{frame}


\begin{frame}
\frametitle{Cartes contre oracles}
\begin{block}
{Deux approches pour un protocole d'information client/serveur
(\emph{Attention} : vocabulaire pas vraiment normalisé encore.)}
{
\begin{enumerate}
\item<2->La carte : le serveur envoie au client des informations sur
la topologie du réseau, et le client sélectionne.
\item<3->L'oracle (« \foreign{You're the Oracle?} »
« \foreign{Bingo. Not quite what you were expecting, right?} ») : le
client envoie au serveur la liste des pairs potentiels et le serveur
les trie, puis indique les meilleurs
\end{enumerate}
}
\end{block}
\end{frame}

\begin{frame}
\frametitle{La carte, avantages et inconvénients}
La carte donne au client une complète liberté de choix du pair.

\only<2->{Mais elle nécessite le transfert de données de grande
taille.}

\only<3->{Et elle oblige le FAI à déclarer sa topologie, ses relations
d'affaire, etc.}

\end{frame}

\begin{frame}
\frametitle{L'oracle, avantages et inconvénients}
L'oracle minimise les calculs faits sur le client.

\only<2->{L'oracle éviter au FAI de dévoiler sa carte.}

\only<3->{Mais il oblige le client à indiquer ses pairs potentiels.}

\only<4->{Et le client ne peut rien vérifier, il doit faire confiance.}

\only<5->{« \foreign{Morpheus believes in you, 
Neo and no one, not you or 
even me can convince him 
otherwise.} »}
\end{frame}

\begin{frame}
\frametitle{Le protocole ALTO}
\begin{block}
{ALTO (\foreign{Application-Layer Traffic Optimization}) sera le protocole standard de l'IETF pour interroger
un serveur afin de trouver le meilleur pair.}
{Le problème qu'essaie de résoudre ALTO est décrit dans le RFC
5693 \url{http://www.bortzmeyer.org/5693.html}}
\end{block}
\end{frame}

\begin{frame}
\frametitle{Le protocole ALTO, suite}
\only<2->{ALTO permet les \emph{deux} fonctionnements : carte
(\foreign{target-independent}) et oracle (\foreign{target-aware}).
\begin{itemize}
\item<3->Le serveur envoie au client une \foreign{Network Map} et
une \foreign{Cost Map} et le
client calcule,
\item<4->Ou bien le client envoie une liste d'adresses IP au serveur
et le serveur renvoie une \foreign{Cost Map} qui indique leurs coûts
(distances). Le client peut indiquer le type de coût qui l'intéresse
(coût de routage, par exemple).
\end{itemize}
}
\end{frame}

\begin{frame}
\frametitle{ALTO en Oracle}
\includegraphics[scale=0.47]{alto.pdf}
\end{frame}

\begin{frame}[fragile]
\frametitle{Détails techniques sur ALTO}
ALTO est actuellement décrit dans
l'\foreign{Internet-Draft} \computer{draft-ietf-alto-protocol-06}. 

Il utilise HTTP, avec des requêtes codées en JSON.

Un PID (\foreign{provider-defined Network Location identifier})
identifie un groupe de machines proches, par exemple :
\begin{info}
"Montpellier-POP" : [
                       "192.0.2.0/26",
                       "198.51.100.0/25"
                   ],
"Internet" : [ "0.0.0.0/0" ]
\end{info}
\end{frame}

\begin{frame}[fragile]
\frametitle{Un exemple de requête ALTO}
Un exemple trivial où il n'y a que deux PID, ma ville et le reste de l'Internet :
\begin{info}
POST /map/filter/pid/cost HTTP/1.1
Host: alto.example.net:6671

       {
           "srcs" : [ "Montpellier-POP" ],
           "dsts" : [ "Montpellier-POP", "Internet" ]
       }

       HTTP/1.1 200 OK
...
         "map" : {
             "Montpellier-POP": 
                 { "Montpellier-POP": 0,  "Internet": 2 }
         }
\end{info}
\end{frame}

\begin{frame}
\frametitle{Autres documents sur ALTO}
\begin{itemize}
\item RFC 5693, décrivant le problème.
\item \computer{draft-ietf-alto-reqs}, le cahier des charges du
protocole. L'exigence ARv06-25 impose les deux modes, carte et oracle.
\item \computer{draft-ietf-alto-protocol}, le protocole.
\item Autres documents, par exemple sur les problèmes de déploiement
(qui doit payer pour ce nouveau service ?), ou bien sur des extensions
au protocole\ldots
\end{itemize}
\end{frame}


\begin{frame}
\frametitle{Mécanisme, pas politique}
\begin{itemize}
\item Le protocole ALTO est « neutre ». Il n'impose pas de politique particulière,
\item<2-> Tout le monde peut faire tourner un serveur ALTO, pas
uniquement le FAI
\item<3-> ALTO ne dit pas comment obtenir les informations mises dans
les \foreign{maps}. Configuration statique ou bien mesure dynamique
(et, dans ce cas, BGP, OSPF, ping, etc),
c'est le serveur ALTO qui décide.
\item<4-> ALTO ne dit pas comment le client peut utiliser cette
information, ni même s'il doit l'utiliser.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{État actuel d'ALTO}
Le groupe de travail a fourni un effort important et les principes de base
semblent acquis.

\only<2->{Le RFC important, celui sur le protocole, n'est pas encore
fini (en retard sur les prévisions initiales). On
peut espérer sa publication dans la première moitié de 2011.}

\only<3->{Il y a déjà plusieurs mises en \oe{}uvre du protocole dans son état
actuel. (Démo à IPTComm 2010 en août.)}
\end{frame}

\begin{frame}
\frametitle{Histoire d'ALTO}
\begin{enumerate}
\item Atelier IAB en mai 2008. RFC
5594 \url{http://www.bortzmeyer.org/5594.html}
\item Première réunion informelle IETF en juillet 2008 à
Dublin \url{http://www.bortzmeyer.org/alto-wg.html}
\item Création du groupe de travail en novembre 2008
\item Tests P4P publiés en 2009, RFC 5632 \url{http://www.bortzmeyer.org/5632.html}
\item Premier RFC du groupe ALTO en octobre 2009, RFC 5693
(\foreign{Problem statement})
\end{enumerate}
\end{frame}

\end{document}