Étude de l’accès Internet de l’Île de La Réunion.
1er comité de suivi de thèse.
Étudiant:
Réhan NOORDALLY
Encadrants:
Pascal ANELLI, Directeur de thèse, maître de conférence à l’université de la Réunion HDR,
Richard LORION,maître de conférence à l’université de la Réunion
Contenu du document
1 Introduction 4
2 Travaux Réalisés 7
2.1 Planning prévisionnel . . . 7
2.2 Orientation de la thèse . . . 7
2.3 ICMP . . . 8
2.3.1 Résultats obtenus . . . 8
2.4 TCP . . . 9
2.4.1 Exemple de Résultats . . . 10
3 Conclusion 13 3.1 Perspectives . . . 13
3.1.1 Objectifs à court termes... . . 13
3.1.2 ...et à moyen terme . . . 13
3.2 Valorisation scientifique . . . 14
3.3 Bilan . . . 14
Bibliographie 14
Chapitre
1
Introduction
La croissance du nombre [1] de terminaux mobiles et la diversités de ces usages ont en- traînés le développement de grands nombres d’applications diverses. L’utilisation de ces terminaux dans le cadre personnel (réseaux sociaux) ou professionelle [2] (le cloud com- puting par exemple) conduise à une génération massive de données (aussi connue sous le terme de big data.) Outre le traitement de ces données, leur transport entre le client et le serveur va devenir problématique. D’abord parce que, la croissance du volume est très importante1. Mais les problèmes de croissance de l’Internet ne sont pas nouveaux [3]. Par exemple, comme l’espace d’adressage est devenu insuffisant. La version dite IPv6 répond à cette problématique par un espace d’adressage agrandi. Cependant elle ne propose pas une réponse opérationnelle à la croissance du trafic. Les solutions pour traiter la croissance du volume des données transmises sont de deux ordres:
• l’augmentation physique des ressources de transfert par l’ajout de liens supplémen- taires ;
• l’augmentation virtuelle de la capacité de transfert. Cette augmentation peut être obtenue en rapprochant les contenus des consommateurs ou des nouveaux paradigmes de communication. L’efficacité des protocoles de communication (comme la diminution du taux de retransmissions par exemple) peut aussi être une piste.
La première approche souffre d’un coût de réalisation important et d’un délai de mise en oeuvre qui reste incompatible avec la croissance du trafic.
On définira une zone isolé comme une zone du monde où le maillage est très faible et où les délais de connections sont longs. La Zone Océan Indienne, avec l’île de La Réu- nion et l’île Maurice en sont de bon exemple. Ainsi, dans ce contexte, des problèmes d’infrastructures peuvent apparaître. Ces îles possèdent une connectivité faiblement mail- lée reposant sur deux câbles sous-marin SAFE et LION. Dans certain cas, une voie de secours satellitaires reste disponible. De part cette topologie, le problème de saturation sera plus aigu. Le risque est de voir les besoins en trafic augmenter jusqu’à dépasser les ressources disponibles. Ceci est particulièrement criant lorsqu’une artère est coupée ou en
1Selon IDC en 2011, la quantité annuelle de données produites dans le monde est évaluée à 1,8 zettaoctets avec une croissance de 50% par an.
panne. L’augmentation de la capacité de transfert ne sera pas infinie (pour des raisons techniques et de coût) et tout du moins, ne suivra pas la croissance de la production des données. De plus, la longueur du câble (composante distance) ajoute une latence dans les communications diminuant, ainsi la performance du service. En effet, cette performance dépend des délais qui sont importants dans le cas de des îles de la zone Océan Indien comme nous allons le montrer par la suite.
Par ailleurs, la nature même des contraintes sur le service de communication a changé.
De la consultation de contenu (web, vidéo à la demande), les communications sont dev- enues plus interactives (téléphonie sur Internet, jeux en lignes, etc.) [4]. La particularité de ces usages de l’Internet actuel repose sur la contrainte de latence imposée au service de communication. La latence se définit comme le délai entre la source et la destination.
Elle est aussi un paramètre important dans la performance du service de consultation de contenu. Cette métrique se compose d’un terme lié à la distance et d’un autre lié aux conditions de trafic en d’autre terme du débit disponible. En somme, le modèle actuel d’un réseau (longue distance) pour joindre les serveurs situés ailleurs dans le monde va vite être confronté à des problèmes de saturation (à cause du big data) et donc de performance (à cause de l’augmentation du délai introduit par la saturation).
De manière complémentaire, les contraintes des services de communication peuvent être corrigées par des améliorations des protocoles de transport. La motivation est de rendre le transport plus efficace afin d’avoir le moins de bande passante perdue (par les retrans- missions, par les périodes d’inactivités, etc.). En plus des contraintes des services de communication, ce sont aussi les contraintes applicatives telles que celles des applications interactives qui sont un facteur d’évolution des protocoles de transport. La table 1.1 nous donne les caractéristiques différenciant les deux types d’applications.
Élastiques Interactives
Élastiques Non élastiques Interactive Non interactive S’adapte aux condi-
tions du réseaux
Nécessite des garanties sur cer- tains paramètres
Réaction rapide at- tendue
Pas de bornes strictes sur le temps d’acheminements S’adapte à d’autres
changements
Bornes strictes
sur le temps
d’acheminement de l’information Tolère des varia-
tions d’une certaine amplitude
Application en temps réel
Généralement inélastique
Table 1.1: Propriété des familles d’applications - Source : P. U. TOURNOUX Ainsi, les propositions telles que DCCP2, qui permet de diminuer le débit d’émission et d’éviter le congestion collapse et des taux de pertes important, et les codes à effacement visent le transfert de ces données de manière plus efficace que TCP. Mais quelques soit le trafic, le contrôle de congestion reste un élément central dans la performance du service de communication de l’Internet. Il est donc essentiel qu’il fonctionne correctement et qu’il soit adapté à son environnement.
2Datagram Congestion Control Protocol
Le projet de thèse proposé s’inscrit dans la seconde approche. Dans cette dernière, la recherche s’oriente d’une part vers les réseaux centrés sur le contenu. Dans ces réseaux, le fournisseur des données n’est plus le seul dépositaire du contenu. Ce dernier est diffus dans le réseau. Des noeuds sont les dépositaires du contenu pour d’autres noeuds clients en espérant ainsi rapprocher le contenu de son consommateur. Ce schéma s’inscrit dans l’évolution introduite par les applications P2P3 et SDN4.
Afin de connaître les solutions potentielles à déployer pour améliorer la QoE, le trafic se doit d’être mesuré, de même que la performance du réseau Internet.
Ces mesures permettront d’identifier les évènements de congestions et les paramètres de performances. Pour cela, il existe deux techniques de mesures du trafic. On parle de mesures actives (injection de paquets dans le réseau) ou passives (simple écoute du réseau).
De nombreux outils sont disponibles librement5. [5].
Cette thèse vise à proposer une amélioration du service de transfert du réseau Internet pour La Réunion. Le réseau Internet va être confronté au problème de big data. Ce problème va être une vraie difficulté pour les zones isolées fortement peuplées comme les îles. En effet, la communication s’effectue entre des serveurs éloignés et les utilisateurs insulaires qui empruntent des ressources de communications limitées. Le big data est un fort risque de saturation de cette ressource capitale pour ces territoires. Cette ressource est fortement partagée avec l’apparition des nouveaux terminaux et donc de nouvelles ap- plications. Ces dernières génèrent une grande variété de types de trafic qui s’additionne à ceux déjà existants. Ce trafic diversifié devient ainsi de plus en plus compliqué à anal- yser. La création d’une base de données représentative des zones isolées pour des études et le développement d’outils pour la fouille de données et l’analyse du trafic constitue une première retombée.
La croissance de l’augmentation du trafic pourra être établie dans cette phase de mesure.
Cette information pourra donner une date approximative de la saturation de la connec- tivité Internet de La Réunion. Il est important de connaître cette date car elle donne le délai pour la mise en œuvre de solutions. Ainsi, en plus de la prévision d’évolution du trafic, l’analyse des particularités du trafic des zones isolées sera une autre retombée. Le service de communication ne doit pas se détériorer dans le temps. Ainsi dans le cas de La Réunion, cette connaissance précise du trafic et des défauts doit aider à orienter les choix d’évolutions technologiques et protocolaires pour maintenir et/ou améliorer le service de communication dans le temps. Le développement et l’expérimentation de nouveaux proto- coles ou mécanismes de transport sur une connectivité a forte latence aura une retombée régionale mais également au niveau de la communauté scientifique.
Ce document s’articule autour de 2 parties. Nous allons tout d’abord présenter les travaux réalisés jusqu’à présent. Nous aborderons dans la conclusion les perspectives, les actions de valorisation et le bilan.
3Peer-to-peer
4Software-defined networking
5http://www.caida.org/tools/
Chapitre
2
Travaux Réalisés
2.1 Planning prévisionnel
Le planning prévisionnel de cette thèse sur les 3 années est le suivant:
1. ère Année :
- État de l’art et orientation de la thèse;
- Mise en place d’une expérimentation sur les délais ; - Développement de l’outil d’analyse TCP;
- Prise de contact avec les FAIs locaux ; 2. nde Année :
- Déploiement de la plateforme d’écoute et d’analyse;
- récupération des premiers résultats ; 3. ème Année :
- Présentation des résultats auprès des partenaires ; - Rédaction du mémoire de thèse ;
- Soutenance ;
Ce planning m’a servi de guide pour ma première année en m’indiquant les objectifs à atteindre.
2.2 Orientation de la thèse
La lecture d’article est une activité que je mène en continue. L’état de l’art réalisé jusqu’à présent permet de définir l’orientation que je souhaite donné à ma thèse. L’étude et l’analyse du trafic entre dans le domaine de la métrologie [6,7], mais me suit rendu compte que les études de métrologie pure ne sont plus d’actualité depuis quelques années. Il
n’empêche que l’on trouve de bons conseils en lisant ce que d’autres auteurs ont pu effectués durant leurs travaux [8]. Au niveau métrologie, l’accent est désormais mis sur la qualité de service(QoS) [9], le ressenti utilisateur(QoE) [10]. Les défauts de connectivité comme les délais [11], le phénomène de bufferbloat [12], la congestion [13] par exemple, sont des points impactants sur la performance du service de communication. Le traitement de la sporadicité du trafic TCP, comme le propose Wai [14], peut offrir un gain en terme de QoS et de QoE. Les expérimentations portent rarement sur les zones isolées (comme La Réunion ou l’Île Maurice). Suite à mon état de l’art, j’ai décidé d’orienter ma thèse sur l’amélioration de la QoE des zones isolées. définir formellement une zone isoléePour proposer des solutions, il faut d’abord identifier précisément les défauts. Pour cela, il faut réaliser réaliser des analyses sur le trafic de ses zones. L’amélioration de la QoE passera par potentiellement par une augmentation de la QoS et des modifications protocolaires.
La première étude porte sur la mesure du délai Réunion-Métropole.
2.3 ICMP
Comme indiqué dans l’introduction, l’utilisation d’Internet a évolué et les délais courts sont devenu une nécessité. L’importance prise par le groupe RITE [15] dans l’explication sur les causes des délais, y compris au grand public [16] en est un bon exemple. Dans le cas de l’ile de la Réunion, quels sont les termes de délai significatifs ?
Pour répondre à cela et trouver les raisons de ces long délais, nous avons déployer une dizaine de Raspberry Pi [17] sur l’île, mais également à l’île Maurice, connecté à différents opérateurs et utilisant différents technologies de connexion (ADSL, VDSL, FIBRE, RE- NATER). Ce choix de différentes technologies nous permettra également de comparer les temps d’accès au réseau. Ces outils vont au travers de la commande ping mesurer en continue les délais entre la Réunion et 4 serveurs web non-coopératifs répartit en France métropolitaine (Bordeaux, Nantes, Strasbourg, Toulouse). Nous avons choisi les paquets ICMP après lecture de l’étude réalisé par Wenwei [18] qui compare ce choix à TCP. Les deux techniques se valent mais la commandeping paraissait la plus simple à déployer en peu de temps. La commandeparis-traceroute va nous indiquer les changements de route possible pour nos requêtes ICMP. Le choix de cet utilitaire s’explique par la nécessité d’avoir une meilleure visibilité des routes prises et de prendre en compte le problème du load balancing [19]. Notre étude est uni-directionnel dans le sens où l’on mesure les délais vers la métropole et non l’inverse. Cette étude permettra également de mesurer le délai minimal entre l’île et al métropole.
2.3.1 Résultats obtenus
Les résultats présentés ci-dessous proviennent de la semaine 50 (du 15 au 21 Décembre 2014) et tiennent compte des défauts dû aux problèmes remontés par les opérateurs sur le câble SAFE les semaines précédentes [20].
On a 3 critères qui entrent en jeux dans nos résultats : la destination, la technologie et la taille du paquet ICMP (variant de 28 à la taille MTU).
Les figures 2.1 et 2.2 comparent les RTT des différentes technologies pour des paquets ICMP allant à Strasbourg avec des tailles de respectivement de 64 et 1024 octets. Ces figures sont des fonction de probabilité de densité (PDF :Probability Density Function).
Cela nous donnes la probabilité d’obtenir ces valeurs de RTT.
Ces deux figures nous montrent que la taille du paquet n’a pas eu d’impact vers cette destination pour 34 des technologies, mais on remarquera que les "gros" paquets ont un RTT plus court sur la technologie ADSL. L’hypothèse formulé à la lecture de ces résultats est : Les paquets de la technologie ADSL ont des routes différentes selon leur poids. Pour
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
100 1000 10000 100000
Prob
time (ms) Cumulative data function
adsl renater fibre vdsl
Figure 2.1: CDF de paquets ICMP de taille 64 bits à destination de Stras- bourg
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
100 1000 10000 100000
Prob
time (ms) Cumulative data function
adsl renater fibre vdsl
Figure 2.2: CDF de paquets ICMP de taille 1024 bits à destination de Strasbourg
affirmer ou infirmer notre hypothèse, nous regarderons les différences entre les routes prises en utilisant l’indice de Jaccard :
Jς(Ri−1, Ri) =|Ri−1T Ri|
|Ri−1
SRi| (2.1)
Cette équation compare 2 ensembles et varie entre 0 et 1, respectivement si les ensembles sont totalement différents ou identiques.
Cette étude sur les délais permet également d’analyser les schémas redondants, par ex- emple est-ce que chaque week-end on obtient une augmentation/dimunition du RTT ou est-ce que les pics relevés lors des diagrammes d’analyse temporelle sont toujours placés au même endroit. Ainsi la durée de notre étude, que nous fixons arbitrairement à 1 an, nous permet d’avoir un jeu de donnés dans lequel nous pourrons faire de l’échantillonage et utiliser des techniques de "data mining".
Mais les délais ne sont qu’une cause, l’explication des valeurs élevées est peut-être dû aux protocoles de transport utilisés.
2.4 TCP
On cherche a mesurer le trafic et la performance du réseau régional. Pour cela, nous allons étudier les premières métriques sur lesquelles nous allons travailler et qui sont regroupés dans le tableau 2.1, avec l’aspect qualité correspondant :
Afin de ne pas perturbé les mesures, nous allons utiliser une approche passive en capturant l’ensemble du trafic utilisateur que nos partenaires mettront à notre disposition. Et pour cela, nous avons réfléchi à l’endroit où déployer notre station d’écoute comme l’indique le schéma 2.3.
Cette station de capture se place au plus près de la connexion opérateur-SAFE. Elle permettra de capturer, si les FAIs jouent le jeu, la totalité du trafic interne à l’île et les paquets internationaux. Nous pourrons ainsi évaluer la part de chaque destination.
À la base, j’ai voulu rentabiliser le temps passé sur mes travaux de stage de fin d’étude de master2 en me basant sur un outil déjà développé, dans ce cas précisTCP Trace [21], en le modifiant pour qu’il me donne les résultats voulus. Au final, le temps dédié à la com- préhension du code étant trop importante, j’ai pris la décision de développé mon propre outil en alliant les langages Bash et Python(scapy) plus les logicielsBro pour la géolo-
Nom de la métrique Aspect
RTT QdS/QdE
Duré de la communication Qds/QdE
Throughput QdS/QdE
Débit écoulé montant QdS
Débit écoulé descendant QdS
Paquets perdus QdS
Paquets déséquencés QdS
Paquets dupliqués QdS
Efficacité du support QdS
Gigue QdS
Évènement de congestion Protocole/QdS Taille des différentes fenêtres Protocole
Taille des flots Protocole Protocole de transport Protocole Service de communication Protocole Taux de connexion TCP inabouties QdS/QdE
Geolocalisation des serveurs
Table 2.1: Métriques étudiées
POP
Routage externe SAFE Interconnexion Fibre Optique
Internet
Routeur FAI
Wimax FTTB FTTH NRA Sonde passive
Routage Interne Réseau GAZELLE
Figure 2.3: Schéma de localisation de la sonde de capture
calisation des serveurs et Gnuplot pour l’obtention de résultats sous forme graphiques.
Cela permettra une évolution simplifié du code en cas d’ajouts de métriques. Ce code est toujours en développement et n’a pu être réellement testé pour la vérification du rendu des résultats.
2.4.1 Exemple de Résultats
Les résultats ci-dessous proviennent d’une trace capturé sur RENATER avec différents sites internet visités à partir de mon poste de travail.
Sur la figure 2.4, on mesure l’efficacité général de la trace. Pour cela, on utilise la for- mule suivante1−throughputgoodput . Legoodput est la quantité de trafic effectivement reçu, alors que le throughput est la quantité de données envoyée. Au niveau du rappatriement de
0 0.2 0.4 0.6 0.8 1
0.01 0.1 1
p(X)<X
cdf_efficacite
up down
Figure 2.4: CDF de l’efficacité de la trace analysé
l’information, près de la moitié à une efficacité inférieur à 1. Pour l’envoi de requêtes et d’informations, le taux se situe entre 0.1 et 1, avec une pré-dominance(preque 70%) inférieur à 1. Nous avons donc une connectivité avec une efficacité majoritairement basse que soit du trafic montant ou descendant. Les questions formulées à partir de ce graphique est : Existe t’il énormément de défauts pour engendrer une aussi faible efficacité ? Mais quel est-le taux d’efficacité d’une connection sur un réseau maillé ?
Au niveau de l’évolution de la taille de la fenêtre de réception qui fluctue selon l’indication du champsWindow Scale. La figure 2.5 illustre l’ensemble des valeurs prises par le champ par un courbe de densité cumulative. La figure 2.6 montre l’évolution de la fenêtre pour une connexion particulière. Une connexion se définit pour nous par le quadruplé suivant : {adresse ip source, port source, adresse ip destination, port destination}.
Sur chaque figure, on peut remarquer que l’évolution des fenêtres suivent la même ten-
0 0.2 0.4 0.6 0.8 1
10 100 1000 10000 100000
p(X)<X
cdf_size_windows
up down
Figure 2.5: CDF Window
0 2000 4000 6000 8000 10000 12000 14000 16000
-1 0 1 2 3 4 5 6 7 8
Octets
Variation des fenetre TCP
10.230.30.134:34137 95.101.67.60:https
Figure 2.6: Evolution de la fenêtre de con- nexion
dance.
Au niveau géolocalisation, la figure 2.7 indique que la totalité de notre trafic n’atteint pas 100%. Cela est dû à des connection à des sites internes à l’Université et qui donc ne ne s’affiche pas. Mais au final, c’est près de la moitié des connections qui remontent vers l’Europe et plus spécifiquement vers les Pays-Bas 2.8.
Avec cette géolocation, on peut étudier la partie temporelle avec les temps d’accès à ces serveurs. On voit ainsi que la moitié de nos RTT, tel qu’illustré sur la figure2.9, sont inférieur à 500ms et 25% sont proches des 200ms, ce qui est la tendance générale pour une connexion normale sur RENATER d’après l’étude sur les délais que l’on a vu précédemment.
0 20 40 60 80 100
%
Country Pourcentage de connexion par pays
NA EU AF
Figure 2.7: Géolocalisation par continent
0 20 40 60 80 100
%
Country Pourcentage de connexion par pays
NL IE GB FR DE
Figure 2.8: Géolocalisation par pays eu- ropéens
0 0.2 0.4 0.6 0.8 1
0.01 0.1 1 10 100
p(X)<X
rtt (sec) CDF_RTT
RTT_cdf
Figure 2.9: Densité cumulative RTT
D’autres résultats comme le nombre d’évènements de congestion, le nombre de connexion et leur durée, les différentes applications et protocoles utilisés, ou encore d’autres infor- mations sont redirigés vers un fichier texte et non sous format graphique.
Chapitre
3
Conclusion
3.1 Perspectives
Les perspectives que je vais abordé sont le futur que je souhaite donner à ma thèse. j’ai décidé de séparer mes perspectives en 2 catégories d’objectifs : ceux à court termes donne les objectifs que je vais mettre en place pour ma seconde année de thèse. J’utilise "court terme" car ma seconde année est déjà entamé. Les objectifs à moyen terme sont les objectifs que je vais viser dans ma 3ème année.
3.1.1 Objectifs à court termes...
Les objectifs à court termes sont ceux que l’on souhaite mettre en place pour la seconde année. Le premier que je dois réalisé est la prise de contact avec les opérateurs. Sans cette partie, une grande partie de ma thèse en pourra être réalisé. Sans la participation des FAIs, la capture du trafic régional ne pourra se faire, son analyse non plus. La mise en place de la sonde de capure dépends donc directement de la participation des FAis à mon projets.
Le second est le développement de l’outil d’analyse. Comme je l’ai dis précédemment, je souhaite continuer à dévelloper mon outil en fonction des métriques que l’on souhaite étudier. L’objectif principal de cette seconde année consiste en la présentation d’un article à une conférence. Le point central de ce premier papier serait les délais en zone isolé car l’expérimentation est déjà bien avancé. Je souhaite également débuter la rédaction de mon mémoire de thèse.
3.1.2 ...et à moyen terme
Les objectifs pour ma troisième année sont au nombre de X. Je souhaite tout d’abord finaliser l’analyse des traces d’écoute, si j’ai la possibilité d’en obtenir, et rédiger un article sur les défauts des zones isolés. Une fois les défauts répertoriés, nous pourrons commencer la réflexion sur comment résoudre ces problèmes. Ensuite, je poursuivrai la rédaction de mon mémoire, avec une soutenance prévu pour le début de l’année 2017.
3.2 Valorisation scientifique
Les zones isolées sont des zones "oubliés" par les scientifiques au niveau réseau. C’est une chance pour nous que de valoriser les résultats obtenus que ça soit sur l’étude des délais, surtout que l’augmentation physique de la capacité de transfert est extrêment couteuses avec l’obligation de raccordement à un câble sous-marin et n’est donc pas une solution à long terme. L’identification des différents délais, surtout ceux qui sont incompréssibles, nous indiqueras une vois à suivre pour résoudre le problème des fortes latences.
De plus, l’analyse du trafic indiquera les autres problèmes qui devront être résolus dans l’objectif d’améliorer la QoE des internautes des zones isolées. En sachant que l’outil développé n’est pas "révolutionnaire" et qu’il ne pourra être valorisé, nous devrons nous concentré sur la méthode utilisée et surtout les résultats obtenus. Ces derniers ainsi que les traces d’origines serviront de bases, avec l’accord des FAIs, pour l’étude des zones isolées en étant publiés sous licence GPL2.
3.3 Bilan
Ma première difficulté rencontrée fut l’absence d’article sur la connectivité des zones isolées, mais en même temps c’est une très bonne opportunité pour nous que d’être les premiers à travailler sur ce point. C’est un challenge de grande importance que d’attirer l’attention des collègues scientifiques sur les problèmes rencontrés dans notre cas alors qu’ils n’y sont pas soumis. La seconde difficulté est le peu de structuration que j’avais dans une journée, passant d’un "projet" à un autre, sans prendre la peine de finaliser un minimum ce que je faisait. Du coup, je perdais plus de temps que je n’en gagnais.
Les problèmes que je vais rencontrer prochainement sont des problèmes matériels. En effet, actuellement je travaille sur des espaces de stockages trop faibles pour contenir les résultats brutes de mon étude sur les ping et les résultats analysables sous forme graphique. De même, le stockage risque d’un problème important dans l’étude TCP au vu de la grosse quantité de données qui transitent sur le réseau Internet de l’Île de La Réunion. Si ne pou- vons avoir accès à des données proposés par les FAIs, nous nous redirigerons vers le trafic universitaire ou alors demander à des particuliers. Je compte faire, prochainement, une de- mande d’écoute du trafic des laboratoires auxquels je suis rattaché pour valider l’outil que j’ai développé et vérifier son passage à l’échelle au niveau temps de traitement par exemple.
Bibliographie
[1] ONU, “The millennium development goals report 2013,” Organisation Nations United, Tech. Rep., 2013.
[2] J. Bughin, “Clouds, big data, and smart asserts : ten tech-enabled business trends to watch,” MacKinsey Quartely, vol. 0, pp. 1–14, 2010.
[3] C. Emmnouilides, “Internet usage : predictors of active users and frequency of use,”
Journal of interactive marketing, vol. 14, pp. 17–32, 2000.
[4] A. Callado, “A survey on internet traffic indentification,” IEEE Communications Sur- veys and Tutorials, vol. 11, pp. 37–49, 2009.
[5] H. Kim, M. Fomenkov, K. Claffy, N. Brownlee, D. Barman, and M. Faloutsos, “Com- parison of internet traffic classification tools,” IMRG WACI, 2007.
[6] P. Owezarski, “Que nous dit la métrologie sur le futur d’internet?” Proceedings of JRES, 2001.
[7] K. R. Houerbi, “Mesures et caractérisation du trafic dans le réseau nationaluniversi- taire (rnu),” Ph.D. dissertation, Ecole nationale des sciences de l’informatique, uni- versité de manouba, Tunis, 2009.
[8] W. John, S. Tafvelin, and T. Olovsson, “Passive internet measurement: Overview and guidelines based on experiences,” Computer Communications, vol. 33, no. 5, pp.
533–550, 2010.
[9] P. Owezarski, P. Abry, K. Salamatian, D. Kofman, A. Aussem, F. Guillemin, and P. Robert, “Métrologie des réseaux de l’internet,”Rapport dinal de l’Action Spécifique du département STIC du CNRS, vol. 88, 2003.
[10] H. J. Kim, D. H. Lee, J. M. Lee, K. H. Lee, W. Lyu, and S. G. Choi, “The qoe evalu- ation method through the qos-qoe correlation model,” in Networked Computing and Advanced Information Management, 2008. NCM’08. Fourth International Conference on, vol. 2. IEEE, 2008, pp. 719–725.
[11] J. Aikat, J. Kaur, F. D. Smith, and K. Jeffay, “Variability in tcp round-trip times,” in Proceedings of the 3rd ACM SIGCOMM conference on Internet measurement. ACM, 2003, pp. 279–284.
[12] M. Allman, “Comments on bufferbloat,” SIGCOMM Comput. Commun.
Rev., vol. 43, no. 1, pp. 30–37, Jan. 2012. [Online]. Available:
http://doi.acm.org/10.1145/2427036.2427041
[13] V. Kushwaha and R. Gupta, “Congestion control for high-speed wired net- work: A systematic literature review,” Journal of Network and Com- puter Applications, vol. 45, no. 0, pp. 62 – 78, 2014. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S1084804514001453 [14] D. X. Wai, P. Cao, and S. H. Low, “Tcp pacing revisited,” 2006.
[15] B. Bob, B. Anna, P. Andreas, H. David, R. David, T. Ing-Jyh., G. Stein, F. Gorry, G. Carsten, and W. Michael, “Reducing internet latency: A survey of techniques and their merits,” in IEEE Communications Surveys & Tutorials. IEEE, 2014 (To appear).
[16] R.I.T.E., “Slow internet? -more bandwith is not the answer,” 2014. [Online]. Available:
http://riteproject.eu/2014/10/23/slow-internet-more-bandwidth-is-not-the-answer/
[17] “Raspberry pi, official website.” [Online]. Available: http://www.raspberrypi.org/
[18] L. Wenwei, Z. Dafang, Y. Jinmin, and X. Gaogang, “On evaluating the differences of tcp and icmp in network measurement,” Computer Communications, vol. 30, no. 2, pp. 428–439, 2007.
[19] B. Augustin, X. Cuvellier, B. Orgogozo, F. Viger, T. Friedman, M. Latapy, C. Mag- nien, and R. Teixeira, “Avoiding traceroute anomalies with paris traceroute,” inPro- ceedings of the 6th ACM SIGCOMM conference on Internet measurement. ACM, 2006, pp. 153–158.
[20] “Câble sous-marin rompu, internet qui mouline,” 2014. [Online]. Available:
http://www.clicanoo.re/450621-cable-sous-marin-rompu-internet-qui-mouline.html [21] “Tcptrace, official homepage.” [Online]. Available: www.tcptrace.org
