Vous êtes sur la page 1sur 147

QoS cooperative pour ladaptabilite des protocoles de

Transport dans le contexte des activites de groupe


Francois Armando

To cite this version:


Francois Armando. QoS cooperative pour ladaptabilite des protocoles de Transport dans le
contexte des activites de groupe. Computer Science [cs]. INSA de Toulouse, 2010. French.
<tel-00462528>

HAL Id: tel-00462528


https://tel.archives-ouvertes.fr/tel-00462528
Submitted on 10 Mar 2010

HAL is a multi-disciplinary open access Larchive ouverte pluridisciplinaire HAL, est


archive for the deposit and dissemination of sci- destinee au depot et a la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publies ou non,
lished or not. The documents may come from emanant des etablissements denseignement et de
teaching and research institutions in France or recherche francais ou etrangers, des laboratoires
abroad, or from public or private research centers. publics ou prives.
THSE
En vue de l'obtention du

DOCTORAT DE LUNIVERSIT DE TOULOUSE


Dlivr par lInstitut National des Sciences Appliques
Discipline : Informatique et Tlcommunications

Prsente et soutenue par Franois ARMANDO


Le 17 Fvrier 2010

QoS cooprative pour ladaptabilit des protocoles de Transport


dans le contexte des activits de groupe

JURY
Mr Nazim Agoulmine Rapporteur
Mme Pascale Vicat-Blanc Primet Rapporteur
Mme Louise Trav-Massuys Examinateur
Mr Amine Berqia Examinateur
Mr Christian Fraboul Examinateur
Mr Jacques Turbert Examinateur
Mr Christophe Chassot Directeur de Thse
Mr Khalil Drira Directeur de Thse

Ecole doctorale : Mathmatiques Informatique Tlcommunications de Toulouse (MITT)


Unit de recherche : Laboratoire dAnalyse et dArchitecture des Systmes (LAAS)
Directeurs de Thse : M. Christophe Chassot, M. Khalil Drira
ma mre Juliette,
Marie,
Louise . . .
Avant-propos

Je remercie tous ceux sans qui ce travail naurait jamais t possible...

iii
iv
Table des matires

Table des matires v

Liste des figures vii

Introduction 1

1 Etat de lart 5
1.1 Dfinitions de la Qualit de Service . . . . . . . . . . . . 7
1.1.1 Principes gnraux . . . . . . . . . . . . . . . . . . . . . 7
1.1.2 QoS spcifique aux applications multimdias . . . . . . . 8
1.1.3 Paramtres de QoS rseau . . . . . . . . . . . . . . . . . 9
1.2 Approche base rservation pour la garantie de la QoS 10
1.2.1 Modles prcurseurs pour la garantie de QoS . . . . . . . 10
1.2.2 Extensions : gestionnaires de ressources . . . . . . . . . . 12
1.3 Approche base adaptation pour loptimisation de la
QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 Lauto-adaptabilit des futurs services de communication 14
1.3.2 Les cadres architecturaux pour la gestion de ladaptation 17
1.4 QoS au niveau de la couche Transport . . . . . . . . . . 19
1.4.1 Les protocoles de Transport classiques . . . . . . . . . . 20
1.4.2 Les nouveaux protocoles de Transport, architecture
configurable . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.3 Le Framework ETP : Enhanced Transport Protocol . . . . 22
1.4.4 Mcanismes de Transport Classiques . . . . . . . . . . . 24
1.4.5 Mcanismes de Transport pour le multimedia . . . . . . 29
1.4.6 Gestion cooprative de la QoS . . . . . . . . . . . . . . . 31
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2 Principes darchitecture dun systme de gestion


auto-adaptative de la QoS 35
2.1 Besoins des acteurs du systme NETQOS . . . . . . . . . . 37
2.1.1 Dfinition des acteurs . . . . . . . . . . . . . . . . . . . 37
2.1.2 Besoins des utilisateurs et des applications . . . . . . . . 38
2.2 Description de larchitecture . . . . . . . . . . . . . . . . 39
2.2.1 Prsentation gnrale du systme . . . . . . . . . . . . . 39
2.2.2 Description des services . . . . . . . . . . . . . . . . . . 41
2.2.3 Architecture fonctionnelle du systme . . . . . . . . . . . 43
2.3 Spcification dtaille des composants de lentit APA 49
2.3.1 Choix remarquables de conception . . . . . . . . . . . . 49
2.3.2 Spcification dtaille du PDM . . . . . . . . . . . . . . 54
2.3.3 Spcification dtaille du PAM . . . . . . . . . . . . . . . 55

v
2.3.4 Spcification dtaille du PEM . . . . . . . . . . . . . . . 56
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3 Gestion cooprative de la QoS au niveau Transport 63


3.1 Rpartition de la bande passante . . . . . . . . . . . . . . 67
3.1.1 Contexte applicatif et exemple : les OIU . . . . . . . . . . 67
3.1.2 Description des Oprations dIntervention dUrgence (OIU) 68
3.1.3 Problmatique et approche . . . . . . . . . . . . . . . . . 70
3.1.4 Formalisation du problme . . . . . . . . . . . . . . . . 73
3.1.5 Calcul de la rpartition de bande passante . . . . . . . . 74
3.1.6 Problme P1 : minimiser la bande passante globale cde 75
3.1.7 Ajout dun deuxime critre et dfinition du problme P2 :
minimiser lexcdent de bande passante libre . . . . . . 80
3.1.8 Conclusion sur lutilisation des critres de minimisation
globale (z1 ) et de minimisation des excdents (z2 ) . . . .
82
3.2 Gestion cooprative de la QoS dans le systme NETQoS 82
3.2.1 Identification des connexions . . . . . . . . . . . . . . . 82
3.2.2 Classe MoMe . . . . . . . . . . . . . . . . . . . . . . . . 83
3.2.3 Mise en uvre du processus de coopration . . . . . . . 84
3.2.4 Diagramme de squence pour la coopration . . . . . . . 84
3.3 Outils et protocoles pour la rcupration des infor-
mations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.3.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.3.2 Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.3 Protocoles de routage . . . . . . . . . . . . . . . . . . . 88
3.3.4 Fonctions de Monitoring dans ETP . . . . . . . . . . . . 88
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4 Mise en uvre et valuation de performance 93


4.1 Evaluation de performance de lAPA . . . . . . . . . . . . 95
4.1.1 Spcification du contexte de mesure . . . . . . . . . . . . 95
4.1.2 Mtriques mesures . . . . . . . . . . . . . . . . . . . . 97
4.1.3 Scnarios de mesures, rsultats et analyses . . . . . . . . 97
4.1.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.2 Gestion cooprative de la QoS et rpartition de dbit 104
4.2.1 Contrle de congestion utilis : TFRC . . . . . . . . . . . 105
4.2.2 Mise en uvre de lapproche . . . . . . . . . . . . . . . 105
4.2.3 Etude de faisabilit - Scnarios simples . . . . . . . . . . 106
4.2.4 Etude de faisabilit - Scnarios plus complexes . . . . . . 109
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Conclusion 119

Bibliographie 123

Bibliographie de lauteur 129

Glossaire 133

vi
Liste des figures

1.1 Architecture dune entit de Transport . . . . . . . . . . . . . 24


1.2 Espace des protocoles ordre et de fiabilit partiels . . . . . 30
1.3 Architecture dun Transport multimdia connexions
dordre partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1 Acteurs du systme NETQOS . . . . . . . . . . . . . . . . . . 37


2.2 Les entits principales du systme NETQoS . . . . . . . . . 40
2.3 Use Cases du systme NETQoS . . . . . . . . . . . . . . . . . 41
2.4 Use Case du service S3 : Satisfaire les politiques des acteurs 42
2.5 Use Case S3/1 : Satisfaire une politique utilisateur excutant
une application NETQoS-Unaware . . . . . . . . . . . . . . . 44
2.6 Diagramme de structure composite de NetQoS . . . . . . . . 45
2.7 Diagramme de structure composite de lAPA . . . . . . . . . 47
2.8 Diagramme de classe de lAPA . . . . . . . . . . . . . . . . . 51
2.9 Autre classes du package APA . . . . . . . . . . . . . . . . . 52
2.10 Diagramme de squence dun provisionnement au niveau
Rseau/Transport (UC1) . . . . . . . . . . . . . . . . . . . . . 53
2.11 Diagramme de squence dune adaptation au niveau R-
seau/Transport (UC2) . . . . . . . . . . . . . . . . . . . . . . 54
2.12 Diagramme de classe du PDM . . . . . . . . . . . . . . . . . 55
2.13 Diagramme de classe du PAM . . . . . . . . . . . . . . . . . 56
2.14 Diagramme de classe des composants internes PEM . . . . . 57
2.15 Problme des multiples entits gres un niveau donn . . 57
2.16 Interactions de lETP Agent avec lAPA.PEM et les entits ETP 58
2.17 Diagramme de classe de lETP agent . . . . . . . . . . . . . . 59
2.18 Diagramme de structure composite de lETP Agent . . . . . 59
2.19 Stack ETP Agent pour une adaptation distance . . . . . . . 60

3.1 Scnario dOpration dIntervention dUrgence . . . . . . . 69


3.2 Rseau de connexions . . . . . . . . . . . . . . . . . . . . . . 76
3.3 Rseau de connexions . . . . . . . . . . . . . . . . . . . . . . 78
3.4 Classe CollaboratingConnection . . . . . . . . . . . . . . . . 83
3.5 Classes Modifies . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.6 Diagramme de squence Policy Violation . . . . . . . . . . . 85
3.7 Diagramme de squence pour une adaptation cooprative . 86
3.8 Fonctions de Monitoring dans ETP . . . . . . . . . . . . . . . 89

4.1 Les entits principales du systme NETQoS . . . . . . . . . 95


4.2 T-APA : Histogramme du % de requtes de provisionne-
ment servies par intervalle de temps . . . . . . . . . . . . . . 98

vii
4.3 T-APA : Temps de transit pour une requte de provisionne-
ment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.4 T-APA : Temps de transit moyen dune requte de provi-
sionnement vs. taux darrive . . . . . . . . . . . . . . . . . . 100
4.5 APA : Evolution de la longueur des files dattente en fonc-
tion du temps . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.6 APA : Histogramme du % de requtes dadaptation servies
par intervalle de temps . . . . . . . . . . . . . . . . . . . . . . 102
4.7 PAM : Temps de transit pour une requte dadaptation . . . 103
4.8 APA : Temps de transit moyen pour une requte dadapta-
tion vs. taux darrive . . . . . . . . . . . . . . . . . . . . . . 103
4.9 T-APA : Evolution de la longueur des files dattente . . . . . 104
4.10 Scnario I : Flux suivant la mme route . . . . . . . . . . . . 107
4.11 Scnario II : Flux de sources distinctes . . . . . . . . . . . . 108
4.12 Scnario III : Flux de sources distinctes, bottleneck distincts 109
4.13 Topologie rseau de la simulation ns-2 . . . . . . . . . . . . 110
4.14 Dbit TFRC modifi . . . . . . . . . . . . . . . . . . . . . . . 112
4.15 Dbit TFRC modifi et liss . . . . . . . . . . . . . . . . . . . 113
4.16 Dbit TFRC modifi - version 2 . . . . . . . . . . . . . . . . . 114
4.17 Dbit TFRC modifi et liss - version 2 . . . . . . . . . . . . . 114
4.18 Dbit TFRC + Shaper avec connexions donneuses non
contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

viii
Introduction

Contexte, problmatique et positionnement des


travaux

La "Socit de linformation", telle quest qualifie notre socit actuelle,


repose sur la communication grande vitesse, haut dbit, et en tout
point. Ceci sest concrtis par la multiplication de nouvelles technolo-
gies de communication, tant au niveau des rseaux sans fil, tels que WiFi
ou Bluetooth, que des quipements terminaux, incluant aujourdhui des
quipements mobiles de type PDA ou smartphone.
Ces volutions prfigurent une mobilit gnralise des utilisateurs de
lInternet. Dans un futur proche, la communication devrait tre diffusable
encore plus largement par une utilisation massive de processeurs embar-
qus de type capteurs ou actionneurs : lInternet sera alors extrmement
diffus, mobile et htrogne, au moins sa priphrie, cest--dire l o
se situeront les utilisateurs, quils soient humains ou plus gnralement
objets communicants.
Lhorizon qui se dessine ainsi est celui dun Internet ambiant au travers
duquel :
les utilisateurs seront mobiles et donc susceptibles dutiliser des res-
sources en diffrents endroits, sans avoir considrer leur environne-
ment courant ;
la communication sera diffusable partout mais avec des caractristiques
diffrentes (en termes de dbits, de taux de pertes, . . .) en fonction des
ressources disponibles ;
le rseau et ses services seront mme de satisfaire, voire danticiper
les besoins des utilisateurs, en tirant au maximum partie des capacits
de lenvironnement, incluant les utilisateurs eux-mmes, dans lequel
ceux-ci volueront.

Cet environnement futur ouvre des perspectives applicatives nouvelles


autorisant la coopration dynamique dutilisateurs mobiles. Nous nous
intresserons particulirement au cadre dfini par des exercices tels que
les Oprations dIntervention dUrgence (OIU) en situation de crise. Dans
ce type de contexte :
le rseau est en tout ou partie constitu par les utilisateurs eux-mmes ;
les ressources en bande passante sont potentiellement limites et va-
riables en fonction de la topologie du rseau, qui peut voluer avec la
progression de la mission ;
les participants appartiennent des groupes structurs, induisant une

1
2 Introduction

hirarchisation potentielle des collaborations susceptible dvoluer avec


lactivit ;
enfin, par la nature des communications (audio, vido) ainsi que par le
caractre durgence de la mission, des besoins apparaissent en terme de
Qualit de Service (QoS) ou de scurit sur les transferts de donnes.

Pour venir en support de ce type dactivits, les futurs services de com-


munication devront tre hautement dynamiques, cest--dire activables
la demande des utilisateurs. Ces services devront galement tre aptes
prendre en compte des besoins et des contraintes multiples et volutifs
dans le temps en fonction de lexercice cibl, de la mobilit des utilisa-
teurs, des flux de donnes changes ou encore des caractristiques de
lenvironnement de communication.
Pour aborder cette dynamicit, ladaptabilit au contexte apparat comme
le concept majeur quauront dfinir et intgrer les solutions proposes.
Il sagit dune part de dfinir de nouveaux modles de reprsentation du
contexte cibl, et dautre part, de traiter dynamiquement les volutions de
ce contexte. La coopration semble un cadre ncessaire pour traiter ladap-
tabilit au contexte. Cette notion existe dj au travers des solutions dites
pair pair dveloppes par exemple au niveau applicatif pour la dcou-
verte de fichiers ou de route dlai minimal ou permettant de contourner
les pare-feu ; elle existe aussi au niveau des rseaux sans fil et ad hoc,
dont les nuds sont constitus par les terminaux, susceptibles de servir
de routeurs entre les utilisateurs trop loigns les uns des autres pour
communiquer directement.
Dans ce contexte, les travaux prsents dans ce mmoire sinscrivent dans
la problmatique de ladaptabilit des systmes de communication pour
la QoS. Plus prcisment, le problme abord porte sur ladaptation dy-
namique et cooprative de protocoles de Transport configurables, pour r-
pondre aux besoins en QoS dapplications multimdias distribues dans
un contexte dactivits coopratives de groupe de type oprations dinter-
vention durgence.

Contributions

De nombreux travaux ont t mens ces dernires annes sur le thme


des protocoles de Transport orients QoS, dabord mcanismes de re-
prise des pertes paramtrables en termes dordre et de fiabilit partiels
[AME 94], puis configurables plus largement par la possibilit dy compo-
ser des mcanismes protocolaires choisis bon escient lorsque ltablisse-
ment de la connexion [KOH 06], [EXP 03b], [EXP 03a].
Partant de la plus rcente des propositions prcdentes (ETP - Enhanced
Transport Protocol), les contributions prsentes dans ce mmoire visent
dune part rpondre au besoin en architecture de contrle pour ladapta-
tion dynamique des protocoles de Transport configurables, et dautre part
rpondre au problme du choix des actions dadaptation de ces proto-
coles dans un contexte dactivits de groupe coopratives. Au travers de
Introduction 3

cette seconde contribution, nous proposons une approche de gestion co-


oprative des protocoles de Transport permettant de prendre en compte
les priorits des communications dduites du caractre hirarchique des
activits de groupe cibles.
La premire contribution a t ralise dans le cadre dun projet europen
(projet IST NETQoS) et porte sur une proposition darchitecture concep-
tuelle pour la mise en uvre de ladaptation des protocoles de communi-
cation, en particulier de niveau Transport. Suivant une approche inspire
dune part par le cadre propos pour la gestion de rseaux base politique
[STE 99], et dautre part par celui de lAutonomic Computing [IBM 06], les
contributions exposes portent de faon plus spcifique sur llaboration
de larchitecture du composant central du systme, charg de concevoir,
dadapter et de faire appliquer des politiques oprationnelles aux entits
en charge de la gestion directe de la QoS, typiquement de niveau Trans-
port.
La deuxime contribution porte sur le problme de la dcision et propose
une approche originale de gestion cooprative des protocoles de Trans-
port pour la QoS dans les activits de groupe. Inspire des propositions
de gestion de la QoS dans les protocoles de Transport multi-connexions
[CHA 96], [OWE 98], [STE 04], lapproche explore vise privilgier les
connexions de Transport les plus prioritaires au dtriment des connexions
les moins prioritaires. Nous nous intressons plus spcifiquement au pro-
blme de la rpartition de la bande passante entre ces connexions, en
ciblant un objectif non plus dquit (comme le vise TCP), mais de dif-
frenciation en fonction de la priorit des connexions. Aprs avoir dfini
le problme et les donnes ncessaires sa rsolution, nous le formulons
sous la forme dun problme de programmation linaire rsolu grce la
mthode du simplexe. Deux critres doptimisation sont dfinis et discu-
ts.

Plan du mmoire

Ce document est structur de la faon suivante :


Le chapitre 1 prsente un tat de lart des propositions de gestion de la
QoS requise par les applications, notamment multimdias. Ces proposi-
tions, qui relvent des diffrents niveaux de larchitecture TCP/IP, sont
classes en deux approches. En premier lieu, il existe des solutions consis-
tant rserver les ressources au niveau du rseau, afin de garantir une
QoS aux applications. En second lieu, dans les environnements o la r-
servation de ressources nest pas envisageable, les solutions consistent
adapter les protocoles de communication afin doptimiser la QoS. Nos
contributions sinscrivent dans cette deuxime approche. Plus spcifique-
ment, elles visent une optimisation de la QoS par le biais des protocoles et
des mcanismes de niveau Transport. Nous prsentons ainsi dans ce pre-
mier chapitre un large ventail de solutions de niveau Transport orientes
QoS, en particulier le concept de protocoles configurables.
Le chapitre 2 prsente notre premire contribution ladaptabilit des pro-
4 Introduction

tocoles de communication, notamment de niveau Transport. Il ne sagit


pas dune contribution consistant modifier, amliorer ou proposer
un nouveau protocole de Transport. Nous proposons dans ce chapitre les
principes darchitecture dun systme de gestion de la QoS permettant de
piloter un protocole de Transport configurable. Larchitecture de ce sys-
tme, dont la conception suit une approche top/down, a t dveloppe
dans le cadre du projet Europen NETQoS. Elle vise dfinir les com-
posants et leurs interactions ncessaires une adaptation dynamique de
solutions de QoS non pas seulement de niveau Transport mais relevant
aussi dautres niveaux, notamment le niveau Rseau. Dans ce chapitre,
nous prsentons la proposition darchitecture gnrale pour le systme
NETQoS, puis nous dtaillons nos contributions spcifiques au projet au
travers du composant de gestion de ladaptation (APA - Automated Policy
Adaptor) et de son interaction avec le protocole de Transport ETP.
Le chapitre 3 prsente notre deuxime contribution, relevant des actions
dadaptation pour optimiser la QoS au niveau Transport dans un contexte
dactivit de groupe de type OIU, induisant des priorits diffrentes entre
les communications. Lide originale consiste envisager une gestion dite
"cooprative" de la QoS, qui permet, en cas de pnurie de ressources, de
privilgier les connexions de Transport les plus prioritaires au dtriment
dautres moins prioritaires. Cette gestion cooprative ncessite de pouvoir
rcuprer des donnes de supervision issues du rseau et des connexions,
puis de prendre une dcision de partage des ressources, avant de dployer
cette dcision et de la mettre en uvre sur les htes dextrmits par lin-
termdiaire dun protocole de Transport configurable. Le principal effort
de notre contribution porte sur la dcision. Nous abordons le problme de
la rpartition de la bande passante entre les connexions en le formulant
sous la forme dun problme doptimisation sous contraintes. Les exten-
sions apporter larchitecture NETQoS pour permettre cette gestion co-
oprative sont galement proposes. Des pistes sont finalement donnes
concernant la faon denvisager la rcupration des donnes de supervi-
sion.
Le chapitre 4 prsente une valuation des contributions apportes dans
les chapitres 2 et 3. Des mesures de performance ralises en simulation
permettent de mettre en vidence le bien fond et les limites des solutions
proposes. Nous prsentons dabord une valuation du composant central
(APA) du systme NETQoS dans loptique den prouver la capacit
rsister au facteur dchelle vis--vis du nombre de requtes traiter. Dans
un deuxime temps, nous montrons la faisabilit du principe de gestion
cooprative de la QoS prsente au chapitre 2. Des implmentations dun
mcanisme de contrle de congestion permettant de mettre en uvre la
dcision prise par le modle doptimisation li la gestion cooprative
sont testes grce au simulateur ns-2.
Enfin, nous terminons le manuscrit par une conclusion gnrale. Celle-ci
rsume les points abords dans ce mmoire ainsi que les contributions
apportes. Elle indroduit galement un ensemble de perspectives pour
structurer les recherches futures autour de la problmatique aborde.
Etat de lart
1
Sommaire
1.1 Dfinitions de la Qualit de Service . . . . . . . . . . . . . 7
1.1.1 Principes gnraux . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.2 QoS spcifique aux applications multimdias . . . . . . . . 8
1.1.3 Paramtres de QoS rseau . . . . . . . . . . . . . . . . . . . 9
1.2 Approche base rservation pour la garantie de la QoS 10
1.2.1 Modles prcurseurs pour la garantie de QoS . . . . . . . 10
1.2.2 Extensions : gestionnaires de ressources . . . . . . . . . . . 12
1.3 Approche base adaptation pour loptimisation de la QoS 13
1.3.1 Lauto-adaptabilit des futurs services de communication 14
1.3.2 Les cadres architecturaux pour la gestion de ladaptation . 17
1.4 QoS au niveau de la couche Transport . . . . . . . . . . . . 19
1.4.1 Les protocoles de Transport classiques . . . . . . . . . . . . 20
1.4.2 Les nouveaux protocoles de Transport, architecture
configurable . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.3 Le Framework ETP : Enhanced Transport Protocol . . . . . 22
1.4.4 Mcanismes de Transport Classiques . . . . . . . . . . . . 24
1.4.5 Mcanismes de Transport pour le multimedia . . . . . . . 29
1.4.6 Gestion cooprative de la QoS . . . . . . . . . . . . . . . . 31
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

C e chapitre prsente un tat de lart des solutions envisages ces der-


nires annes pour rpondre aux besoins en Qualit de Service (QoS)
des applications, notamment multimdias, distribues dans lInternet.
Les dfinitions, les principes gnraux et les standards attachs au concept
de QoS sont tout dabord introduits en section 1.1. Les besoins en QoS des
applications multimdias sont ensuite dtaills, ainsi que les paramtres
de QoS rseaux correspondants.
Les sections 1.2 et 1.3 prsentent deux approches explores pour la gestion
de la QoS de bout-en-bout. La premire approche, base sur le principe de
la rservation de ressources, vise garantir un niveau de QoS aux applica-
tions. La deuxime approche, que nous avons suivie dans nos travaux, est
oriente adaptation aux variations des ressources (et plus gnralement
aux variations du contexte, quil soit applicatif ou rseau) ; elle a pour

5
6 Chapitre 1. Etat de lart

objectif de maintenir une QoS au plus haut niveau, sans chercher garan-
tir celui-ci. Nous prsentons pour chacune delles les solutions existantes
ou proposes dans la littrature, en dtaillant les problmatiques lies
lapproche adaptation.
La dernire partie du chapitre (section 1.4) dtaille les solutions de gestion
de la QoS au niveau Transport de larchitecture de lInternet. Les contri-
butions de cette thse se situent en effet ce niveau de larchitecture,
et visent dvelopper les protocoles, les architectures de contrle et les
modles permettant doptimiser la QoS offerte aux applications par une
adaptation des protocoles de Transport. Nous dcrivons ainsi les proto-
coles de Transport classiques et standardiss (UDP, TCP, SCTP, DCCP),
puis les nouveaux protocoles de Transport qui permettent de prendre en
compte les problmatiques de QoS nouvelles, telles que celles issues des
applications multimdias et de leur utilisation dans des contextes dacti-
vits coopratives. Nous dcrivons en particulier le protocole de Trans-
port ETP (Enhanced Transport Protocol) sur lequel sappuient les travaux
prsents dans ce mmoire. Enfin, cette section dcrit les mcanismes de
niveau Transport ayant un impact direct sur la QoS, cest--dire le contrle
de congestion et le contrle derreur, et introduit les approches de gestion
coopratives qui ont inspir nos travaux.
1.1. Dfinitions de la Qualit de Service 7

1.1 Dfinitions de la Qualit de Service

1.1.1 Principes gnraux

Le terme Qualit de Service (QoS) est abondamment utilis dans les r-


seaux informatiques et reprsente une large collection de technologies et
de techniques qui visent offrir aux applications distribues et leurs uti-
lisateurs des priorits non fonctionnelles (dites de QoS, telles quun dbit
garanti ou un dlai born par exemple) sur le transfert de leurs donnes
de bout-en-bout.
On peut classifier ces technologies et techniques en deux familles :
celle des solutions visant offrir une QoS statistique (Soft QoS) : les pa-
quets, identifis par leur classe de trafic, sont prioriss par rapport aux
autres paquets dans chaque nud du rseau. Suivant cette approche,
aucune garantie ne peut tre faite de bout-en-bout. Des exemples de
solutions de ce type sont notamment DiffServ dans lInternet ou 802.1p
dans les rseaux locaux.
la deuxime famille de solutions vise offrir une QoS garantie (Hard
QoS) : les ressources de communications sont rserves de bout-en-
bout pour chaque flux de trafic identifi pour garantir la performance
requise. Des exemples de solutions de ce type sont notamment IntServ
et RSVP.

Trois notions de QoS ont t dfinies [HAR 01] :


la QoS intrinsque : elle correspondant aux fonctionnalits du rseau
mises en place suivant une approche Soft ou Hard, au provisionnement
du rseau en bande passante, etc. . . ;
la QoS perue : elle reflte lexprience de lutilisateur pour un service
particulier ; elle est influence par les attentes de lutilisateur en compa-
raison au service mesur ;
la QoS value : elle rsulte dune observation (monitoring) selon des
mtriques dfinies.

Enfin, la QoS peut se dfinir de diffrentes manires, comme tant par


exemple :
"La capacit doffrir diffrentes priorits diffrentes applications, utilisa-
teurs, ou flux de donne ou de garantir un certain niveau de performance
un flux de donnes".
Selon ISO 8402 : 1994 [ISO94] : "la totalit des caractristiques dune entit
qui portent sur sa capacit satisfaire des besoins formuls et supposs".
Selon ISO 9001 : 2000 [ISO00] : "le degr auquel un ensemble de caract-
ristiques inhrentes respectent des exigences".
Selon [ITU 93] (et [ETS 94]) : "lensemble des caractristiques dun service
de tlcommunication qui lui permettent de satisfaire aux besoins expli-
cites et aux besoins implicites de lutilisateur du service".
Selon lIETF [CRA 98] : lIETF se focalise plutt sur la notion intrinsque
de la QoS et ne traite pas les aspects de perception. Sa dfinition est la
8 Chapitre 1. Etat de lart

suivante : "Un ensemble de service pr-requis remplir par le rseau lors


du transport dun flux".
Dans ce contexte trs gnral, nous nous intressons maintenant une
famille particulire dapplications, les applications multimdias, et nous
exhibons les besoins en QoS qui en rsultent.

1.1.2 QoS spcifique aux applications multimdias

Ces dernires annes, les volutions conjointes de linformatique et des t-


lcommunications ont conduit lmergence de nouveaux types dappli-
cations distribues, multimdias, telles que les applications de visioconf-
rence ou de vido la demande, ou encore les applications de simulation
interactive distribue.
Comparativement aux applications classiques du type transfert de fichiers,
consultation de pages Web ou encore messagerie lectronique, ces applica-
tions prsentent des contraintes nouvelles sur le transfert de leurs donnes
[WU 00] :
dbit garanti : pour obtenir une qualit de prsentation acceptable, les
applications multimdias ont besoin dun rseau offrant un dbit mini-
mal relativement constant ;
dlai de transit born : contrairement aux transferts de donnes clas-
siques (texte, images fixes,. . .) qui ne sont pas soumis des contraintes
de dlai strictes, les applications multimdias requirent un dlai de
bout-en-bout born li aux mdias eux-mmes (audio ou vido) et/ou
au degr dinteractivit souhait entre leurs utilisateurs. Chaque paquet
doit arriver destination en un temps infrieur au seuil de perception
humain. Si ce nest pas le cas, le paquet peut tre considr comme
inutilisable par lapplication rceptrice ;
fiabilit partielle : la perte de paquets lors du transfert peut conduire
une dgradation de la qualit de prsentation des donnes multimdias.
Il faut donc matriser ces pertes. Mais contrairement aux applications
classiques ncessitant une fiabilit totale dans le transfert de donnes,
les applications multimdias peuvent accepter de perdre certains pa-
quets afin de rpondre par exemple aux exigences temporelles, tout en
offrant une qualit acceptable : on parle alors de contrainte de fiabilit
partielle ;
ordre partiel : de faon analogue, les contraintes dordre, notamment
entre les diffrents flux dune mme application multimdia, ne sont
plus les mmes que dans un transfert de donnes textuelles. En effet, ces
applications impliquent gnralement une manipulation coordonne et
un transfert de plusieurs types de mdia (texte, graphisme, audio, vi-
do,. . .). Il en rsulte un besoin en synchronisation des diffrents mdia
du cot de lapplication rceptrice. Un exemple de synchronisation de
mdia audio et vido est celui du mouvement des lvres et de la voix
(visioconfrence). On parle alors de contrainte dordre partiel .
1.1. Dfinitions de la Qualit de Service 9

1.1.3 Paramtres de QoS rseau

La QoS perue par lutilisateur dune application multimdia est influen-


ce par deux facteurs : la qualit offerte par lapplication elle-mme et la
qualit que lapplication reoit du rseau. Si une application utilise un co-
dec audio ou vido trs bas dbit, alors la qualit sera toujours trs faible,
mme si le rseau ne dgrade pas le flux de donnes par des dlais ex-
cessifs ou des pertes. LITU dfinit dans les recommandations [ITU01],
[REC 02], les paramtres de QoS rseaux suivants :
IPTD (IP Packet Transfer Delay) : ce paramtre dfinit le dlai de trans-
fert quun paquet peut subir durant son transfert dans le rseau. Cette
mtrique est particulirement importante pour les applications ayant
des contraintes de temps rel. Lexemple classique est un flux de voix
sur IP (VoIP) qui doit tre dlivr avec un dlai faible pour permettre
un niveau de qualit acceptable. LIPTD est gnralement exprim par
le dlai minimum, le dlai maximum ou le dlai moyen ;
IPDV (IP packet delay variation) : ce paramtre est dfini comme la
diffrence entre la borne suprieure de lIPTD 103 prs et lIPTD
minimum. Il est important de garder la valeur de lIPDV un niveau
bas ou trs bas pour les applications temps rel ;
IPLR (IP Loss Ratio) : ce paramtre identifie le nombre de paquets IP
perdus sur le nombre total de paquets IP transmis. Il est important de
garder la valeur de lIPLR un niveau bas pour toutes les applications
temps rel qui ne peuvent pas retransmettre les paquets perdus. Pour
les applications non temps rel les paquets perdus doivent tre retrans-
mis. La tolrance des applications multimdias certaines pertes permet
cependant de compenser les imperfections du rseau ;
IPER (IP Packet Error Rate) : ce paramtre identifie le rapport entre le
nombre de paquets errons sur le nombre de paquets transmis ;
IPPT (IP Packet Throughput) : ce paramtre identifie le dbit requis. Il
est gal au nombre total de paquets IP reus sans erreurs sur un inter-
valle de temps donn. Du point de vue de lapplication, le dbit requis
peut tre un paramtre important. Les besoins en dbit sont directement
lis au codec employ.
Face aux besoins en QoS des applications multimdias, deux approches
majeures ont t explores ces dernires annes :
la premire approche est base sur le provisionnement dune QoS ga-
rantie par rservation de ressources dans le rseau, en tenant compte
des besoins des applications exprims en termes de paramtres de QoS
rseau. Cette approche, qui a notamment contribu au dveloppement
dautres modles de services au niveau IP que le service de Best Effort
actuel, est gnralement accompagne de mcanismes de contrle dad-
mission et de mcanismes de signalisation visant mettre en adquation
les besoins applicatifs et la disponibilit des ressources existantes.
la deuxime approche, utilise le degr de tolrance des applications qui
ne ncessitent pas de garanties de QoS dures, et qui peuvent sadapter
certaines variations des ressources du rseau. Ces applications ralisent
des adaptations en cours dexcution qui garantissent un service aux
utilisateurs meilleur que celui offert sans adaptation. Par exemple, en
10 Chapitre 1. Etat de lart

rponse une dgradation de la QoS, une application adaptative peut


remplacer un codec par un autre pour rduire la QoS requise en termes
de dbit.

Nous dtaillons ces deux approches dans les sections 1.2 et 1.3 suivantes.
Rappelons que nos travaux sinscrivent dans lapproche oriente adapta-
tion, applique dans notre cas, non pas directement au niveau applica-
tif, mais au niveau Transport, dans loptique dabstraire les dveloppeurs
dapplications de la complexit de gestion de cette adaptation.

1.2 Approche base rservation pour la garantie de la


QoS

Face aux limites du modle de service de lInternet (qualifi de Best Effort,


cest--dire noffrant aucune garantie de performance), deux groupes de
travail de lIETF, IntServ puis DiffServ, ont t successivement constitus
au milieu des annes 90 pour tudier la mise en uvre de nouveaux ser-
vices au niveau IP dans lInternet. Si les modles darchitectures rsultants
ont pos des bases importantes en matire de gestion de la QoS dans lIn-
ternet, ces modles prsentent cependant des limites importantes qui ont
empch leur mise en uvre effective (cas du modle IntServ notamment)
ou suscit des travaux complmentaires (dans le cas DiffServ notamment).
Dans cette section, nous rsumons les principes des modles IntServ et
DiffSev et nous introduisons les propositions dextension envisages pour
aboutir une garantie de QoS de bout-en-bout invocables la demande.

1.2.1 Modles prcurseurs pour la garantie de QoS

1.2.1.1 Intserv

Le modle IntServ introduit, deux nouveaux services IP en plus du


Best Effort, GS (Guaranted Service) [SHE 97] et CL (Controlled Load)
[WRO 97a]. GS veut satisfaire les besoins des applications fortes
contraintes temporelles ; CL vise rpondre aux applications moins exi-
geantes, et notamment les applications adaptatives. IntServ repose sur
trois principes fondamentaux :
une rservation de ressources est effectue par session au niveau de
chacun des htes et routeurs du chemin de donne ; elle se traduit par
ltablissement et le maintien dun tat ; une session dsigne au moins
un socket de destination (unicast ou multicast) ; la granularit la plus
fine est le flux ;
cette rservation est effectue via le protocole RSVP [BRA 97a]
[BRA 97b], dans le cadre dune phase dtablissement de rservation ;
celle-ci est initie par le(les) metteur(s) mais ce sont le(les) rcepteurs
qui effectuent la requte de rservation. La requte est propage de
routeur en routeur, qui effectuent chacun tour tour un contrle dad-
1.2. Approche base rservation pour la garantie de la QoS 11

mission local, et enregistrent en cas de succs un tat de rservation


pour la session considre ;
le maintien des rservations est assur par la rception de messages
de rafrachissement, mis par le(les) metteurs. Une rservation peut
galement tre relche explicitement.

Larchitecture IntServ [WRO 97b], [WRO 97a], [SHE 97], standardise par
lIETF, est compose des lments suivants :
un ordonnanceur de paquet : il ordonnance les paquets selon une po-
litique potentiellement diffrente du FIFO en utilisant un ensemble de
file dattente et de timers ;
un classificateur : il classe chaque paquet entrant dans les classes de
QoS ;
un contrleur dadmission : il implmente les algorithmes de contrle
dadmission pour dterminer si un nouveau flux peut tre admis ou
pas ;
un protocole de rservation, en loccurrence RSVP [BRA 97b] (Resource
Reservation Protocol), qui vhicule les informations ncessaire la
cration et au maintien dun tat pour chaque flux sur les routeurs
impliqus dans le chemin de donnes.

Le modle IntServ prsente des limites importantes qui en interdisent le


dploiement lchelle du plein Internet :
dune part, le principe de rservation au niveau de tous les routeurs, qui
ncessite un tat par flux et la signalisation ncessaire son maintien ;
se pose alors un problme de mise lchelle de lapproche vis--vis du
nombre de flux QoS ;
dautre part, lignorance de la structure multi-domaines de lInternet ;
cette structure de fait reflte la ncessit dadministrer les domaines de
faon indpendante vis--vis de leurs politiques internes de gestion du
routage, de la QoS ou de la scurit.

1.2.1.2 DiffServ

Le modle DiffServ [NIC 98], [LI 98], [BLA 98] a t conu pour rpondre
aux limites dIntServ. Il est bas sur les principes fondamentaux suivants :
DiffServ carte la notion de flux en cur de rseau, et introduit la
place celle de classe : les paquets dune mme classe sont traits identi-
quement par tous les routeurs du chemin emprunts entre lentre et la
sortie du domaine considr ;
la diffrence dIntServ, DiffServ ne propose pas de contrle dadmis-
sion , mais sappuie sur la notion de contrat (SLA) ngoci entre utili-
sateur et fournisseur, pralablement au transfert des donnes. La partie
technique dun SLA, le SLS , spcifie ( minima) la quantit maximale
de trafic de chaque classe que lutilisateur a le droit dinjecter dans le
domaine, ainsi que le traitement (conditionnement) que subiront les pa-
quets entrants ;
pour une classe de service, un SLA garantit un comportement (PHB
- Per Hop Behavior) identique sur chaque routeur, lchelle du do-
12 Chapitre 1. Etat de lart

maine ; deux PHB ont t standardiss, EF (Expedited Forwarding)


[JAC 99] et AF (Assured Forwarding) [HEI 99]. EF vise un service qui-
valent celui dune ligne ddie, AF vise un service dbit minimal
garanti, avec diffrents niveaux de priorit la perte et au dlai ;
en entre du rseau, le conditionnement des paquets se traduit dabord
par leur classification, sur la base soit dune marque unique (champs
TOS des paquets IPv4 par exemple), soit de plusieurs champs dentte
pouvant porter sur les donnes utilisateur (typiquement sur lentte
des PDU de niveau Transport : n de port source et/ou destination).
Sen suit un contrle de la conformit du trafic au regard du SLS, et
lapplication de mesures de mise au gabarit (policing) pour le trafic non
conforme ; ce policing peut se traduire par le rejet, le retard ou le bas-
culement dans une autre classe. Le trafic conforme est marqu suivant
sa classe dappartenance, puis inject dans le rseau. Lordonnancement
(de type Priority Queuing, Weighted Fair Queuing, etc.) des paquets
dpend de leur classe.

La proposition DiffServ est actuellement considre comme la plus adap-


te pour la gestion de la QoS dans lInternet. Cependant, elle prsente
plusieurs problmes (paramtrage des PHB, tablissement des accords
entre administrateurs des diffrents domaines, . . .). Le passage au multi-
domaine accroit les difficults de gestion de la QoS pour plusieurs raisons :
le provisionnement est plus complexe, car il inclut aussi le dimension-
nement des ressources de chaque domaine par rapport aux contrats
SLA/SLS avec les domaines adjacents.
le contrle dadmission doit tre prolong aux liens inter-domaines pour
assurer la disponibilit des ressources de bout-en-bout.
les domaines de lInternet tant htrognes, les domaines peuvent
fournir des services diffrents. En consquence, une signalisation multi-
domaine doit tre donc mise en place pour grer la continuit de la
qualit de service pour une communication traversant plusieurs do-
maines.

De nombreux travaux ont trait du provisionnement et de la disponibi-


lit des ressources, soit de faon isole, soit dans le cadre darchitectures,
souvent issues de grands projets. Nous les introduisons ci-aprs.

1.2.2 Extensions : gestionnaires de ressources

Le concept de gestionnaires de ressources a t dfini pour aider la


mise en uvre des fonctions ncessaire la rservation, au contrle et la
supervision des ressources dans lInternet. Les gestionnaires de ressources
ont t proposs pour diffrents types de ressources. Dans le contexte des
architectures DiffServ, la notion de Bandwidth Broker (BB) [NIC 99] est
propose pour venir en support du service EF. Un BB est un gestionnaire
des ressources en bande passante dun domaine de lInternet.
Limplmentation dun BB pour la rservation dynamique de bout-en-
bout dans un environnement DiffServ multi-domaines est discute dans
[KHA 01]. Un bandwidth broker centralis dans chaque domaine r-
1.3. Approche base adaptation pour loptimisation de la QoS 13

seau ralise le contrle dadmission, le provisionnement de ressources et


dautres dcisions de politiques. Une architecture base de BB est destine
fournir des services garantis de bout-en-bout en utilisant des garanties
de dlai par flux ou des garanties de dlai par classe. Dans [TER 99], un
systme de BB two-tier est conu et implment pour fournir un provision-
nement de QoS par classe pour une architecture DiffServ. Des systmes de
BB hirarchiques ou distribus permettant un passage lchelle pour la
gestion de la QoS et des SLA ont t proposs en dcouplant le plan de
donnes du plan de contrle de la QoS [ZHA 01]. En utilisant une archi-
tecture base de BB, les routeurs de cur ne maintiennent pas dtats de
rservation de QoS, par flow ou par agrgats. Les tats de rservation de
QoS sont stocks et grs seulement par le BB dans un domaine rseau.
Les architectures base de BB prsentent les avantages suivants :
en maintenant les tats de rservation de QoS seulement sur les BB,
les routeurs de cur ne grent pas les fonctions de contrle de la QoS,
comme le contrle dadmission, ce qui les rend potentiellement plus
efficaces ;
le plan de contrle de la QoS est dcoupl du plan de donnes, permet-
tant au fournisseur de service rseau dintroduire de nouveaux services
sans ncessairement requrir la mise jour matrielle ou logicielle des
routeurs de cur ;
le provisionnement de QoS et le contrle dadmission pour une utilisa-
tion optimise du rseau est possible. Le contrle dadmission est ralis
au niveau du chemin entier, et pas seulement saut-par-saut ;
les problmes de fiabilit, robustesse et passage lchelle du plan de
contrle de QoS sont traits sparment et sans ajouter de complexit
au plan de donnes ;
la QoS utilise diffrents fournisseurs de service Internet et le routage
inter-domaine est possible.

Partant de lensemble de ces concepts, le projet EuQoS [CAL 08], [RAC 08]
a propos et dvelopp une architecture de gestion de la QoS pour lInter-
net multi-domaines htrognes ; leffort dEuQoS a port sur le contrle
dadmission et sur la signalisation en envisageant le provisionnement sur
la base daccords de peering.

1.3 Approche base adaptation pour loptimisation de


la QoS

Complmentaire la vision prcdente, lapproche consistant maintenir


au plus haut niveau la QoS requise sans chercher en garantir pour au-
tant un niveau donn peut savrer incontournable lorsque les ressources
en bande passante ne sont pas prennes dans le temps. Cest par exemple
le cas quand les utilisateurs finaux disposent de moyens de transmission
sans fil et se dplacent durant les communications. Cest dautant plus
ncessaire en rponse aux besoins dynamiques dapplications complexes,
mobiles et coopratives, distribues dans des environnements rseaux h-
14 Chapitre 1. Etat de lart

trognes, en partie sans fil, dont les ressources sont variables et volu-
tives.
Le problme alors soulev est celui du provisionnement dynamique de
services de communication auto-adaptatifs, cest--dire :
invocables la demande, en tenant compte des besoins applicatifs et des
utilisateurs, et des contraintes de lenvironnement de communication,
et capables de sadapter de faon transparente pour les utilisateurs : dune
part, lvolution des besoins de ces utilisateurs, et dautre part,
lvolution des contraintes de lenvironnement de communication, lie
par exemple la mobilit des utilisateurs.

Lobjectif de cette section est de dtailler cette problmatique et dintro-


duire les lments de solutions existants au dmarrage de nos travaux.

1.3.1 Lauto-adaptabilit des futurs services de communication

[FAR 06] explicite quatre phases dans le provisionnement dynamique de


services : la spcification, la dcouverte, le dploiement et la gestion des
services.
Lauto-adaptabilit est un enjeu majeur du provisionnement de ces nou-
veaux services, qui concerne plus spcifiquement les phases de dploie-
ment et de gestion. Les travaux rcents mens dans ce contexte permettent
de mettre en lumire les diffrentes facettes de la problmatique. Aucune
de ces propositions ne fournit encore de solution globale, chacune nabor-
dant quune partie du problme.
Les solutions proposes diffrent en plusieurs points, relatifs aux objec-
tifs cibls, aux niveaux (au sens couches du modle OSI) concerns, aux
actions dadaptation elles-mme, aux caractristiques de ladaptation, et
enfin la faon de grer ladaptation et son autonomie.
Objectifs. Les objectifs cibls par ladaptation sont multiples, et peuvent
par exemple consister :
grer les aspects collaboratifs, comme la gestion de lentre/sortie dy-
namique dutilisateurs dans un exercice de jeux distribus, ou de colla-
boration la rdaction dun document commun,
maintenir la connectivit et de la QoS au niveau du rseau daccs lors
du passage dun rseau sans fil un autre [BAL 04] [KAL 06],
optimiser la QoS de bout-en-bout dans lInternet Best Effort : [WU 01]
[YU 03] [EXP 03b] [AKA 04],
rpondre aux problmes de dploiement lis la prsence de firewalls,
ou grer la confidentialit des informations changes, etc. [SKA 04],
optimiser les ressources des quipements impliqus, en termes dner-
gie, de capacit de calcul/stockage [MAR 01].

Niveaux. Les niveaux considrs relvent aussi bien des couches hautes
(Application, Middleware, Transport) que des couches basses (Rseau,
MAC et Physique) du modle initialement pos par [ZIM 80]. Cependant,
le principe dindpendance des couches est remis en cause, en autorisant
la prise en compte, au niveau considr, dinformations dont la sman-
1.3. Approche base adaptation pour loptimisation de la QoS 15

tique est dun niveau diffrent ; cest le principe de base du cross-layering.


Par exemple, [AKA 04] utilise des informations de niveau MAC comme
paramtres dentre de son adaptation au niveau Middleware/Transport,
pour optimiser la QoS de communications multimdias en temps rel dans
un environnement de rseaux sans fils htrognes.
Adaptation. Les solutions dadaptation proposes dans la littrature sont
multiples et touchent toutes les couches.
Au niveau Applicatif, [WU 01] cible par exemple ladaptation des appli-
cations de streaming vido aux variations de performances de lInternet
Best Effort. Il prsente diffrentes techniques dadaptation par le biais de
deux mcanismes : un contrle de congestion TCP-friendly implantable
de trois faons : bas dbit, bas cartement ou compression dimages,
et un contrle derreur implantable, l encore, de multiples faons : bas
retransmissions contraintes temporellement, bas FEC, bas codage, bas
interpolation.
[SHA 01] propose dadapter le contenu des informations multimdias
en fonction de ltat courant du client, du systme ou du rseau pour
prendre en compte les besoins en QoS de bout-en-bout. Il propose de
sappuyer sur RTP (Real time Transport Protocol), pour implmenter un
schma de contrle bas politique pour les adaptations de niveau applica-
tion. Plusieurs techniques dadaptation de contenu pour lamlioration de
performance perue par lutilisateur final sont ainsi prsentes.
Au niveau Transport, la raction de TCP aux congestions du rseau
(contrle de congestion de type AIMD) est un exemple bien connu dadap-
tation ; cependant, il ne tient pas compte des besoins en QoS temporelles
ou en dbit de lapplication.
DCCP [FLO 06] vise une meilleure adquation en permettant aux utili-
sateurs dactiver le mcanisme de contrle de congestion TCP-friendly
(TFRC par exemple [FLO 08]) le moins pnalisant au regard de ses be-
soins en QoS. Cependant, il noffre pas plus de QoS quUDP et ne permet
pas de rpondre (par exemple) aux besoins minimums en fiabilit des ap-
plications multimdias. SCTP cible une adaptation aux pannes du rseau
via le concept de multi-connexion et de multi-homing [STE 07].
[AKA 04] traite du dploiement de diffrents types dapplications entre
utilisateurs mobiles dans lInternet sans fil htrogne de prochaine gn-
ration. Face leurs besoins en QoS, il propose une couche de Transport
au-dessus de UDP et TCP indpendante du type de rseaux sous-jacents,
visant sadapter aux caractristiques du rseau daccs en cours duti-
lisation. Ladaptation propose repose sur le paramtrage dynamique de
mcanismes de contrle de congestion par le biais dinformations fournies
par le niveau MAC. Ladaptation est locale la machine mettrice.
[WON 01] [EXP 03b] [MOC 05] abordent ladaptabilit des protocoles de
Middleware/Transport sous langle architectural, par le biais de framework
autorisant lassemblage dynamique de mcanismes protocolaires (micro
protocoles, processing modules). La composition vise rendre un service de
Transport adapt un besoin donn, en modifiant au besoin la structure
interne du protocole.
16 Chapitre 1. Etat de lart

Au niveau Rseau, [DAS 04] et [CHE 05] abordent le problme du routage


ad-hoc orient QoS. [SKA 04] cible la configuration dynamique et scuri-
se de services IP au sein dune coalition de rseaux fixes/mobiles grs
de faon indpendante limage des AS de lInternet multi-domaines.
Sa solution suit une approche PBNM et dfinit quatre phases : dfinition
dune relation de confiance entre PDP, ngociation de la politique entre
PDP, configuration dynamique des lments de chaque AS (routeur, fi-
rewall, . . .), et enfin tablissement dun VPN pour le transport des don-
nes relatives au service configur. Cependant, il ne dfinit pas comment
redfinir la politique en cas de problme, laissant cette tche de ladmi-
nistrateur. Dans un contexte analogue, [SAM 05] aborde le problme de
llaboration de politiques auto-adaptatives, cest--dire capable de se re-
configurer en cas de problme. Sa solution repose sur lapprentissage du
contexte courant.
Au niveau MAC, [BAL 04] cible le processus de dcision du handover ver-
tical (i.e. redirection dynamique des flux applicatifs dune interface de r-
seau sans fil vers une autre) pour remdier aux problmes de dconnexion
et de QoS poss un utilisateur mobile dans un contexte de terminaux h-
trognes et de rseaux sans fil htrognes. Une architecture de gestion
du handover base de clusters est propose. Elle inclut un gestionnaire
dadaptation par cluster qui slectionne le rseau adquat partir de la
localisation de lutilisateur, de ses exigences et prfrences, et de la QoS
requise par lapplication. [KAL 06] aborde une solution qui vise amlio-
rer la latence lors du processus de handover. Cependant, les contraintes
de QoS (de type bande passante par exemple) ne sont pas considres.
Caractristiques de ladaptation. Les solutions dadaptation proposes
dans la littrature sont qualifiables de diffrentes faons.
Comportementale vs. architecturale. A limage de TCP et des solutions
proposes par [WU 01] ou [AKA 04], ladaptation peut tre qualifie
de comportementale (ou dalgorithmique), lorsque le comportement des
composants adaptatifs est paramtrable ou modifiable. La structure in-
terne des composants nest en revanche pas modifie, ce qui facilite lim-
plmentation mais limite la capacit dadaptation. En effet, elle peut n-
cessiter lajout de nouveaux comportements, non initialement prvus. Il
est alors ncessaire de recompiler le composant et ladaptation ne peut se
faire en temps rel. Ladaptation est architecturale lorsque la structure in-
terne du composant adaptatif peut tre modifie. A limage de [WON 01]
et [MOC 05], le framework propos dans [EXP 03b] vise la conception
dun protocole de Transport dont la structure peut tre modifie en fonc-
tion des besoins applicatifs et les contraintes du rseau. Le remplacement
dun module protocolaire par un autre est facile implanter si le com-
posant remplaant possde les mmes interfaces que le composant rem-
plac ; lajout ou le retrait de composant(s) est plus complexe implanter :
[EXP 03b] fournit une solution en dotant tous les composants de la mme
interface.
Verticale (local) vs. Horizontale (distribue). Ladaptation peut concerner
un composant local une machine ou distribu entre plusieurs machines
(typiquement, un protocole). Dans le premier cas, ladaptation peut tre
1.3. Approche base adaptation pour loptimisation de la QoS 17

qualifie de verticale. Dans le second cas, on peut la qualifier dhorizon-


tale. [BRI 01] soulve les problmes de synchronisation des entits adap-
tatives paires dans le cas dune adaptation horizontale et propose un pro-
tocole de gestion de cette synchronisation.
Run time vs. Design time.
Ladaptation est qualifie de run-time quand elle est ralise pendant lex-
cution du service. Lorsquil faut recompiler le logiciel considr, ladapta-
tion est qualifie de design-time.
Gestion de ladaptation et de son autonomie. La gestion de ladaptation
et de son autonomie consiste dfinir comment guider ladaptation et
comment la dployer. Ceci ncessite des rponses plusieurs besoins lis :
la dcouverte des services/composants,
lvaluation de ltat des ressources du rseau et des machines : besoin
en mtrologie du rseau, des ressources machines, . . .
lvaluation des performances de ladaptation en vue de la modifier si
elle savre inadapte,
au dploiement de nouveaux paramtres et/ou composants ncessaire
ladaptation, ce qui ncessite une signalisation, une capacit intgrer
en temps rel ces donnes, . . .
et de faon plus gnrale, la conception dune architecture de mise en
uvre des solutions aux besoins noncs.

Adaptabilit multi-niveaux. Lintrt dune adaptabilit diffrents ni-


veaux simultanment a dj t soulign [BRI 01], [LAN 04] ; elle consti-
tue lun des enjeux majeurs du cross-layering. Pour les OIU, ladaptabi-
lit multi-niveaux est ncessaire pour prendre en compte, non seulement
les variations des performances du rseau (au niveau des connexions de
bout-en-bout par exemple), mais galement les changements de coopra-
tion induits par lvolution de la mission.
Cependant, grer ladaptation diffrents niveaux ncessite de dfi-
nir comment coordonner les diffrentes adaptations ; dfaut, elle peut
conduire des performances bien en de de celles cibles. Par exemple,
dans lobjectif doptimiser la QoS de bout-en-bout, une adaptation du d-
bit dmission une dgradation des performances du rseau, la fois au
niveau Application (e.g. par rduction de la taille des images) et au niveau
Transport (e.g par un contrle de congestion de type TFRC [FLO 08]), peut
savrer trop importante et conduire ainsi une solution sous optimale.

1.3.2 Les cadres architecturaux pour la gestion de ladaptation

Offrir un niveau QoS, quil soit garanti ou adaptatif, ncessite la mise


en uvre dune architecture de contrle incluant les diffrentes tapes
franchir pour aboutir une prise de dcision et son application au
niveau des entits impliques dans la fourniture de QoS.
Plusieurs cadres trs gnraux ont t proposs en ce sens, dabord pour
la gestion de rseau base politique, puis de faon gnrale pour la ges-
tion de systmes informatiques autonomes. Nous introduisions ci-aprs
18 Chapitre 1. Etat de lart

deux de ces cadres, dans lesquels sinscrivent nos contributions en termes


darchitecture et pour la prise de dcision.
Cadre architectural pour la gestion de rseaux base politique : la propo-
sition PBNM.
La notion de politique a t introduite comme une approche prometteuse
pour rpondre aux problmes de gestion de rseaux orients QoS. Une
politique correspond un ensemble de rgles de haut niveau qui guident
le comportement des composants du rseau impliqus dans la fourniture
de QoS. Une fois dfinies et stockes dans une base de donnes (rpertoire)
par les administrateurs du rseau, ces politiques sont ensuite traduites
en politiques oprationnelles, excutables par les composants du rseau
impliqus, tels que les routeurs.
Le groupe de lIETF Policy Framework a dvelopp ce concept et pro-
pos un cadre architectural pour une gestion de rseau base politique
[STE 99]. Ce cadre (appel PBNM : Policy Based Networking Manage-
ment) comprend quatre composants : Management Console, Policy Re-
pository, Policy Decision Point (PDP) et Policy Enforcement Point (PEP).
Ces composants utilisent deux sortes de protocoles : les protocoles daccs
la base de stockage des politiques oprationnelles et les protocoles de
transferts de politiques.
La console de gestion (Management Console) fournit une interface entre
ladministrateur et le systme de gestion de la politique. Le rpertoire de
politiques stocke les politiques qui sont applicables un domaine rseau.
Les PDP, appels galement serveurs de politiques, traduisent les poli-
tiques de haut niveau stockes dans la base de donnes, en politiques de
bas niveau. En combinant ces informations avec dautres informations du
rseau (concernant par exemple ltat du rseau), le PDP peut produire les
rgles implmenter par le PEP. Le PEP reoit les rgles issues du PDP
et les dploie sur les lments du rseau correspondants. Le PEP peut
raliser des actions telles que le filtrage ou le marquage des paquets. En
plus de dployer les rgles tablies par le PDP, le PEP peut envoyer des
informations au PDP concernant des changements de configurations par
exemple.
La communication entre le PDP et le PEP est ralise en utilisant un pro-
tocole de transfert de politiques tel que COPS (Common Open Policy Ser-
vice) [DUR 00], dvelopp par lIETF. Les informations transmettre par
COPS sont stockes dans une PIB (Policy Information Base). COPS peut
tre utilis soit en mode Outsourcing, soit en mode Provisionning. En
mode Outsourcing, le PEP contacte le PEP chaque fois quil a besoin din-
formations sur la faon de traiter un vnement particulier. Le PEP rpond
avec les rgles appropries utiliser par le PEP. COPS utilise TCP pour
une communication fiable. En mode Provisioning, le PDP envoie toutes
les informations requises par le PEP linitialisation. Toutes les rgles per-
tinentes sont stockes dans le PEP et tous les vnements sont traits en
utilisant ces informations, sans quil y ait besoin dune nouvelle commu-
nication entre le PDP et le PEP.
[SAM 05] propose damliorer les systmes de gestion de rseau base
1.4. QoS au niveau de la couche Transport 19

politique pour aborder le problme de la gestion autonome de rseau,


notamment DiffServ. Il propose pour cela de sappuyer sur un modle
hirarchique de politiques et sur le concept dapprentissage, permettant
de sadapter dynamiquement aux besoins en QoS.
Nos travaux, mens dans le cadre du projet NETQoS, sinspire de cette
approche dune part en dclinant le concept de politique, et dautre part en
distinguant les rles de PDP et PEP dans ladaptation du niveau Transport.
Cadre architectural pour les systmes autonomes : la proposition IBM.
Plus rcemment, la volont affirme ces dernires annes de dvelopper
les proprits dadaptation des systmes informatiques, quils soient ou
non orients communication, a conduit IBM a proposer le concept dAu-
tonomic Computing ou Calcul Autonomique pour aborder le problme
de la conception de systmes capables de sadapter et de rpondre aux
changements de lenvironnement [IBM 06].
Le calcul autonomique est une mtaphore biologique qui vise, par
exemple dans le corps humain, permettre toute personne de prendre
des dcisions et de faire des efforts sans sencombrer du calcul du rythme
cardiaque ou de la quantit dadrnaline ncessaire son fonctionnement.
Les systmes conus selon ce paradigme doivent donc tre capables dan-
ticiper les besoins et de rsoudre les problmes avec un minimum dinter-
vention humaine.
Pour atteindre cet objectif, un systme autonome doit comporter plusieurs
capacits :
une capacit dauto-configuration (self-configuring), afin de pouvoir
sadapter dynamiquement aux changements denvironnement,
une capacit dauto-rparation (self-healing, pour dcouvrir, diagnosti-
quer et agir afin de remdier aux perturbations du systme,
une capacit dauto-optimisation (self-optimizing), pour ajuster lutilisa-
tion des ressources et quilibrer les charges de travail afin de maximiser
lutilisation de ces ressources,
et enfin une capacit dauto-protection (self-protecting), afin danticiper,
de dtecter, didentifier et de protger le systme vis--vis des menaces.

Nos travaux ne se revendiquent pas pleinement du cadre donn par IBM


mais sinscrivent cependant dans les aspects de self-configuring et self-
optimizing pour la gestion de la QoS.
La section suivante prsente maintenant plus en dtails les propositions
de gestion de la QoS au niveau Transport, cible privilgie de lauto-
adaptation pour la QoS cible par nos travaux.

1.4 QoS au niveau de la couche Transport

La couche Transport se situe au niveau 4 de la pile protocolaire du mo-


dle OSI. Elle a pour but de fournir des solutions de bout-en-bout pour
le transfert des donnes depuis une application mettrice vers une ap-
plication rceptrice travers une interconnexion de rseaux htrognes.
20 Chapitre 1. Etat de lart

Les services rendus par la couche Transport sont directement lis ceux
fournis par la couche Rseau, notamment pour ce qui concerne leur QoS.

1.4.1 Les protocoles de Transport classiques

LIETF a standardis plusieurs protocoles de Transport. Nous pouvons ci-


ter TCP, UDP, SCTP, DCCP. Cependant, les protocoles de Transport princi-
palement utilis dans lInternet sont TCP (Transmission Control Protocol)
et UDP (User Datagram Protocol) qui fournissent respectivement un ser-
vice orient connexion, en mode flux doctets, garantissant ordre total et
fiabilit totale sur le transfert des donnes applicatives (TCP) et un ser-
vice sans connexion orient message, ne garantissant ni ordre, ni fiabilit
(UDP).
TCP [POS 81] base son service de fiabilit totale et dordre total sur un
mcanisme de retransmission visant rcuprer les paquets perdus. Ce
mcanisme entraine une augmentation non contrle du dlai de bout-en-
bout. De plus TCP implmente un mcanisme de contrle de congestion
bas sur les algorithmes de Slow Start et de Congestion Avoidance qui
introduit galement des variations de dbit ou de dlai importantes en
rponse des congestions du rseau.
UDP [POS 80], a contrario, noffre aucune garantie dordre ni de fiabi-
lit. Son implmentation ne repose sur aucun mcanisme de contrle de
congestion, ce qui implique que son utilisation nintroduit pas de variation
incontrle de dbit et de dlai. UDP est donc plus adapt aux communi-
cations multimdias que ne lest TCP. Cependant, le fait quil ne rponde
pas aux congestions du rseau prsente un risque pour lInternet puis-
quune utilisation importante dUDP peut entrainer leffondrement du r-
seau dues aux congestions. De plus, quand les flux sont en concurrence
pour la bande passante, lalgorithme de contrle de congestion de TCP
entraine un partage quitable de la bande passante. Quand il est utilis
avec des flux UDP, qui nimplmente pas de contrle de congestion, TCP
obtient seulement une part minoritaire de la bande passante totale. Les
flux UDP sont alors dits "TCP-unfriendly".
DCCP (Datagram Congestion Control Protocol) [KOH 06] est une alterna-
tive aux protocoles TCP et UDP utiliss dans lInternet. Il offre un service
non fiable, non ordonn, semblable UDP mais fournit un mcanisme
de contrle de congestion qui peut-tre choisi par lutilisateur, comme
par exemple TFRC (TCP Friendly Rate Control) [FLO 08]. DCCP est plus
adapt aux applications interactives utilisant UDP. En plus de permettre
une slection du contrle de congestion, DCCP offre dautres possibilits
comme un mcanisme dacquittement permettant lapplication dimpl-
menter son propre mcanisme de gestion de la fiabilit.
SCTP (Stream Control Transport Protocol) [STE 00] a t initialement d-
velopp pour le transfert des messages de signalisation pour la voix sur
IP (Voice over IP). Cependant, son utilisation est maintenant envisage
pour dautres applications. Les principales caractristiques de SCTP sont
le multi-homing ou encore le concept de multi-flux lintrieur dune
unique association. Ce concept dassociation permet denvisager des m-
1.4. QoS au niveau de la couche Transport 21

canismes spcifiques permettant dtendre le concept de fiabilit partielle


[STE 04]. De plus, des options de TCP sont incluses dans la spcifica-
tion de SCTP comme le Selective Acknowledgment, ou encore la prise en
compte du mcanisme dECN (Explicit Congestion Notification). Enfin,
les attaques de scurit telles que les attaques SYN ne sont plus possibles
avec SCTP.

1.4.2 Les nouveaux protocoles de Transport, architecture configurable

Afin de faire face des environnements de communication de plus en


plus htrognes et aux diffrents besoins des applications, une approche
plus rcente a t explore ces dernires annes, autorisant une configu-
ration la demande du comportement ou de structure des protocoles de
Transport. Le protocole se veut ainsi adaptable en fonction par exemple
des besoins applicatifs ou du contexte rseau.
Ladaptation cible peut tre de deux types : le premier type peut tre
qualifie dadaptation comportementale, ce qui signifie que le protocole
de Transport autorise lapplication spcifier les diffrents paramtres
des mcanismes implmenter. Ce type dadaptation a t tendu par le
concept dadaptation architecturale, qui signifie quen plus des paramtres
des mcanismes que lutilisateur peut choisir, les diffrents mcanismes
eux-mmes peuvent tre choisis par lutilisateur. Par exemple, le choix de
lalgorithme de contrle de congestion de DCCP parmi une liste prdfinie
est un exemple dadaptation architecturale.
La plupart des propositions de cadre (ou framework) de composition de
protocoles configurables sont bases sur la notion de micro-protocole. Un
micro-protocole peut tre dfini comme la brique de base que lon peut
compose, soit dans un schma hirarchique, soit dans un schma non-
hirarchique. Un micro-protocole est un module logiciel qui fournit une
interface de communication permettant son intgration dans une pile de
micro-protocoles. Un framework est un environnement fournissant les ou-
tils ncessaires et les mcanismes pour la composition dune architecture.
[VAN 09] propose une classification des approches existantes selon deux
axes : les approches hirarchiques et les approches non-hirarchiques.
Lapproche hirarchique est base sur le standard OSI dans lequel les
couches de protocole sont empiles les unes au-dessus des autres. Chaque
message est ensuite trait en squence pendant quil transite travers la
pile. Diffrentes architectures suivant le modle hirarchique ont ainsi t
proposes :
x-Kernel : conu au dbut des annes 1990, x-kernel [HUT 91] est des-
tin au systme orient rseau. Il fournit une API lutilisateur pour
crer et instancier dynamiquement diffrents protocoles qui peuvent
tre utiliss par des applications sexcutant sur le systme. Bien que
la proposition x-kernel ne soit pas ddie spcifiquement au Transport,
il sagit dune des premires approches modulaires qui a t la base de
nombreuses exprimentations par dautres concepteurs de framework.
APPIA : bas sur le modle hirarchique introduit dans Ensemble
[BIR 00], APPIA [MIR 01] fournit un framework pour la composition
22 Chapitre 1. Etat de lart

dune pile de micro-protocoles un niveau donn de couche pro-


tocolaire. La notion de "canaux" est dfinie dans APPIA comme la
succession de micro-protocoles quun message applicatif doit traverser.
De plus, APPIA dfinit deux types de message diffrents : les messages
internes dont le rle est de servir la communication intra-couche, et les
messages externes qui doivent tre traits.

Dautres modles ont t proposes pour amliorer les performances des


protocoles configurables. Ces modles sont bass sur le concept de sous-
cription aux notifications dvnements. Les principales propositions sont
Coyote, ADAPTIVE et Cactus.
Coyote : introduit par lUniversit dArizona, Coyote [BHA 98] est le
premier framework de composition de protocoles non hirarchiques,
bas sur des vnements. Il amliore le modle hirarchique de x-kernel
en autorisant une composition non-hirarchique des diffrentes couches
de x-kernel. Le systme est compos dun contrleur principal et de
diffrents micro-protocoles. Les vnements qui guident lexcution du
systme sont dfinis soit par le framework, soit par les micro-protocoles
eux-mmes. Sur occurrence dun vnement, le framework notifie itra-
tivement tous les micro-protocoles qui ont souscrit cet vnement.
ADAPTIVE : lenvironnement de communication ADAPTIVE (ACE) in-
troduit une approche non hirarchique pour concevoir des protocoles
configurables [SCH 93]. ACE automatise la configuration et la recon-
figuration du logiciel de communication en liant dynamiquement les
services aux applications en cours dexcution et en mettant en uvre
ces services avec un ou plusieurs processus ou threads. Ces services sont
implments par une collection de composants orients objets.
Cactus : il sagit dune extension du systme Coyote prsent ci-dessus
permettant dinclure des mcanismes de gestion de la QoS. Cactus in-
troduit lide selon laquelle le comportement des micro-protocoles peut
tre chang "en cours dexcution". Cependant, les implmentations
sont limites puisque tous les micro-protocoles qui pourraient tre re-
quis nimporte quel moment au cours du processus de communica-
tion, doivent tre instancis quand lexcution du protocole dmarre.
Inspir de ces diffrentes contributions, ETP est une proposition de cadre
pour la configuration dynamique de protocoles de Transport oriente QoS.
Nos travaux sappuyant directement sur cette proposition, nous dtaillons
prsent ce framework.

1.4.3 Le Framework ETP : Enhanced Transport Protocol

En combinant les avantages des framework hirarchiques et non hirar-


chiques, ETP (Enhanced Transport Protocol) [EXP 03a] propose une ap-
proche hybride o un plan hirarchique est dfini pour implmenter des
fonctions de contrle de QoS et un plan non-hirarchique pour raliser des
fonctions de gestion de la QoS. En dautres termes, les actions effectues
par paquet sont ralises suivant le modle hirarchique alors que les op-
rations lies la gestion de la connexion suivent le paradigme orient v-
1.4. QoS au niveau de la couche Transport 23

nement. Cette approche permet de clairement sparer les diffrents plans


qui interviennent pour fournir un service de Transport donn.
Le framework ETP a t conu pour rpondre trois besoins ncessaires
la conception dun protocole de Transport configurable orient QoS :
permettre aux applications de communiquer leurs besoins spcifiques
en QoS ;
effectuer le choix des mcanismes permettant de satisfaire au mieux ces
besoins en tenant compte des contraintes du rseau ;
dfinir larchitecture de mise en uvre de ces mcanismes, celle ci
devant autoriser lajout de nouveaux mcanismes pour sadapter
dautres contextes de rseaux et dapplications. Ces problmatiques ont
t traites en utilisant des mcanismes issus du monde de lIntelligence
Artificielle par [VAN 09].

Larchitecture de mise en uvre des mcanismes de Transport sarticule


autour de deux plans : un plan de contrle et un plan de gestion :
plan de contrle : il contient les oprations excutes de manire syn-
chrone sur les donnes applicatives (ADU) mises ou reues. Cest dans
le plan de contrle quest ralise la composition des mcanismes per-
mettant dappliquer la politique choisie pour offrir le service attendu.
Limplmentation de ce plan est faite suivant le modle des architectures
hirarchiques de type V_STREAMS [RIT 84]. Les mcanismes sont im-
plants sous la forme de composants (classes JAVA par exemple) appe-
ls modules de traitement (processing modules), communicants par mes-
sage et sexcutant de manire squentielle. Cette structure permet de
remplacer facilement un mcanisme par un autre ou dajouter un mca-
nisme, si cela est ncessaire ;
plan de gestion : cest dans le plan de gestion que sont dcides, va-
lues et modifies au besoin les politiques appliques par le plan de
contrle. Limplmentation de ce plan est faite selon le modle des
architectures non-hirarchiques du type Cactus [GAR 01] ou ADAP-
TATIVE [SCH 93]. Concrtement, il sagit doprations (mcanismes
locaux ou protocolaires) effectues sur les flux de donnes de manire
asynchrone. L encore, ces oprations sont implantes laide de pro-
cessing modules. Comparativement aux oprations du plan de contrle
(qui portent sur chaque paquet individuellement), les oprations du
plan de gestion sont ralises sur des chelles de temps plus grandes,
car elles ncessitent par exemple des informations statistiques relatives
au rseau. Nous verrons cependant dans la suite que le plan de gestion
inclut galement des traitements par paquet.

La section suivante dtaille larchitecture dimplmentation de ces deux


plans.

1.4.3.1 Implmentation des plans de contrle et de gestion

Pour implanter ces deux plans, le framework ETP propose une architec-
ture unifie (en mission comme en rception) comprenant un composant
pour le plan de gestion et deux composants pour le plan de contrle :
24 Chapitre 1. Etat de lart

le composant du plan de gestion (mg de la Figure 1.1) est charg de


rcuprer les informations provenant du rseau ou des applications, et
de faire appliquer la politique de QoS adquate. Par exemple, mg peut
calculer le dbit dmission ncessaire lvitement des congestions et
communiquer cette valeur aux composants du plan de contrle.
les composants du plan de contrle chargs dappliquer la politique
dfinie au niveau du mg, sont le ControlOUT pour le traitement des
flux de donnes sortants et le ControlIN pour les flux de donnes
entrants. Cest par exemple au niveau du composant ControlOUT que
sera applique la politique de mise en forme du trafic pour respecter le
dbit dmission, calcul par le mg.

Figure 1.1 Architecture dune entit de Transport

Pour adapter le protocole au contexte applicatif et/ou rseau, le choix


effectu repose sur la composition dynamique de mcanismes. Cette com-
position apparat dans larchitecture interne des composants des plans de
contrle et de gestion : celle ci nest pas fixe mais peut tre constitue dau-
tant de processing modules que ncessaires. Pour charger dynamiquement
les modules protocolaires appropris, une description en langage XML de
larchitecture de processing modules dsire doit tre fournit ETP (par
exemple lors de la cration dun socket par lapplication). Le framework
fournit tous les outils ncessaires pour convertir la description de la com-
position en XML en linstance du protocole de Transport correspondant.
Les sections suivantes dcrivent prsent les mcanismes protocolaires
ayant un impact sur la QoS offerte aux applications. Les mcanismes
classiques (non orients QoS) sont tout dabord prsents, puis les m-
canismes orients QoS.

1.4.4 Mcanismes de Transport Classiques

Les principaux mcanismes de Transport ayant un impact direct sur la


QoS sont le contrle de congestion et le contrle derreur.
1.4. QoS au niveau de la couche Transport 25

1.4.4.1 Contrle de congestion

Le contrle de congestion est un mcanisme visant adapter le dbit


dmission des entits Transport en fonction de ltat du rseau, en parti-
culier en cas de congestion dun ou plusieurs routeurs impliqus dans le
chemin de donnes des connexions de Transport considres. Deux types
de contrle de congestion existent dans la littrature [WU 00] : orient
fentre et orient dbit.

1.4.4.1.1 Contrle de congestion orient fentre Ce mcanisme est celui utilis


par le protocole TCP dans sa version premire [POS 81]. Le principe est
de tester la bande passante disponible au niveau du rseau en incrmen-
tant une fentre dite de congestion limitant lenvoi des donnes sur le
rseau. La dtection de perte est ensuite considre comme une conges-
tion du rseau et entrane la diminution de cette fentre. Les mcanismes
du contrle de congestion de TCP sont le Slow Start et le Congestion Avoi-
dance. Ce mcanisme entrane une variation du dbit dmission. De plus,
il est gnralement coupl un mcanisme de reprise des pertes (par re-
transmission) induisant une augmentation du dlai de transmission des
donnes potentiellement inacceptables pour les applications multimdias.

1.4.4.1.2 Contrle de congestion orient dbit Ce type de contrle vise di-


minuer lamplitude des variations de dbit induites par un contrle de
congestion orient fentre. Il peut tre mis en uvre linitiative de lmet-
teur ou du rcepteur et comporte deux variantes : bas test et bas modle.
Contrle linitiative de lmetteur
Bas test : cette technique consiste adapter le dbit dmission grce
une estimation de la bande passante disponible. Pour cela, lap-
plication utilise un paramtre de QoS (comme le taux de perte par
exemple) et augmente (respectivement diminue) le dbit dmission si
ce taux est au-dessous (respectivement au-dessus) dun certain seuil.
Notons que les entits communicantes doivent mettre en place un m-
canisme de feedback leur permettant dchanger linformation taux
de perte .
Bas modle : cette technique se base sur un calcul plus explicite
de la bande passante disponible grce un modle caractrisant le
dbit dune connexion TCP. Ce modle est donn par la formule 1.1
suivante :

1.22 MTU
D= (1.1)
RTT p
avec :
D = dbit dmission
p = taux de pertes
MTU = unit maximale de transmission du rseau
RTT = temps aller-retour des paquets
On remarque que le calcul du RTT ncessite de connatre la date de
rception du paquet. Un mcanisme de feedback et destampillage
26 Chapitre 1. Etat de lart

temporel des paquets est alors ncessaire. Un contrle bas sur un tel
modle permet aux entits mettrices dtre TCP-friendly.

Contrle linitiative du rcepteur


Bas test : cette technique est base sur le principe dabonnement
des couches correspondant des dbits dmission (et donc des
qualits de prsentation) qui augmentent graduellement. Cette m-
thode est utilise dans les environnements multipoints o les rcep-
teurs sabonnent des groupes diffrents correspondant des d-
bits dmission diffrents. Cest une mthode empirique : le rcepteur
sabonne une couche ; sil y a congestion, il sabonne une couche
impliquant la rception dun dbit plus faible.
Bas modle : le rcepteur estime explicitement la bande passante
disponible (grce la formule 1.1 par exemple) et sabonne en cons-
quence la couche correspondante.
Notons que lon peut galement envisager de coupler les mcanismes
linitiative de lmetteur et du rcepteur. On parle alors de contrle de
dbit hybride .

1.4.4.2 Contrle derreur

En dpit de lutilisation des mthodes exposes ci-dessus, les pertes res-


tent cependant invitables et une rcupration des pertes simpose. Dans
loptique de prendre en compte dautres besoins en QoS que la fiabilit
(par exemple le dlai ou le dbit), il convient dtudier les consquences
de lapplication des mcanismes retenus.
Les techniques dites de FEC (Forward Error Correction) consistent ap-
pliquer des bits de redondance dans les paquets transmettre afin de fa-
ciliter leur correction (voire leur reconstitution). Il faut cependant prendre
en compte laugmentation de dbit qui en rsulte.
Les techniques de type ARQ (Automatic repeat request) sont envisa-
geables si lon prend en compte la contrainte de dlai. Autrement dit, une
retransmission est possible si larrive dun paquet retransmis ne dpasse
pas un seuil temporel fix. Notons que la dtection des pertes en rception
ncessite une numrotation des paquets.
Nous dtaillons prsent ces deux types de techniques.

1.4.4.2.1 Forward Error Correction (FEC) Les mcanismes de type FEC [LUB 02]
sont bass sur lajout de bits de redondance ou dinformations suppl-
mentaires (flux redondants par exemple) permettant la reconstitution du
flux si certains paquets ont t perdus lors de la transmission.
Au niveau Application, un premier mcanisme, bas sur le codage la
source (SFEC), consiste ajouter dans les paquets de donnes plusieurs
versions plus ou moins compresses du flux mis. Le mcanisme de re-
couvrement des pertes, permet lentit de pouvoir toujours prsenter
lutilisateur final le flux mis, mme avec une qualit de prsentation
rduite.
1.4. QoS au niveau de la couche Transport 27

Au niveau Transport, les mcanismes de type FEC ne peuvent pas utiliser


des mthodes de compression comme celles voques ci-dessus. On utilise
donc des mthodes bases sur le codage canal qui consiste ajouter pour
un nombre n de paquets de donnes, k bits de redondance. Contrairement
au mcanisme bas sur la compression au niveau applicatif, le recouvre-
ment des pertes grce au codage canal permet de reconstruire le flux avec
la mme qualit que le flux mis.
Les principaux inconvnients des mcanismes de type FEC rsultent de
laugmentation du dbit dmission due aux informations de redondance,
ainsi que de laugmentation de dlai due aux algorithmes de codage et de
compression.

1.4.4.2.2 Automatic Repeat Request (ARQ) Les mcanismes ARQ [FAI 02] sont
bass sur la retransmission des paquets perdus. Nous prsentons dans la
suite les principaux protocoles existants bass sur ce principe.
Stop-and-Wait : ce mcanisme consiste pour lmetteur envoyer un
paquet de donnes et attendre son acquittement avant lenvoi de
la prochaine donne. Cot rcepteur, lacquittement dune donne est
envoy si elle a t reue en squence. Cela ncessite donc une num-
rotation des paquets en mission, permettant galement de dtecter les
paquets dupliqus. On peut galement mettre en place un mcanisme
de dtection des paquets reus en squence mais corrompus lors du
transfert. Lentit rceptrice peut alors envoyer un acquittement ngatif
(NACK) pour demander la retransmission du paquet corrompu. Sur
rception dun acquittement ngatif, lentit mettrice retransmet le
paquet. Sur rception dun acquittement positif, elle envoie la donne
suivante. Pour rsoudre le problme li la perte dun acquittement,
lentit mettrice doit mettre en place un temporisateur de retransmis-
sion (timer) associ chacun des paquets envoys. Sur expiration de ce
timer, le paquet correspondant est retransmis.

Go-Back-N : contrairement au Stop-and-Wait, ce mcanisme permet


lenvoi de plusieurs donnes successivement, avant rception du pre-
mier acquittement. Ces donnes, non encore acquittes, sont stockes
jusqu la rception dun acquittement. En rception, une donne reue
en squence entrane lenvoi de lacquittement correspondant la don-
ne reue. Si une perte est constate (par larrive dune donne hors
squence), tous les paquets ayant un numro de squence suprieur
au numro attendu sont rejets. Sur occurrence dune perte, deux m-
canismes peuvent tre mis en place par le rcepteur. Soit il envoie un
acquittement ngatif (NACK) correspondant au premier paquet hors
squence, soit il nenvoie aucun acquittement. Au niveau de lmetteur,
la rception dun acquittement positif permet de librer une place dans
la fentre dmission (fentre glissante). La rception dun NACK en-
trane la retransmission de tous les paquets stocks partir du paquet
perdu. Si le rcepteur nenvoie pas de NACK ou si lacquittement est
perdu, la retransmission se fait grce la mise en uvre de timer au
niveau de lmetteur. De la mme manire, lexpiration dun timer de
retransmission entrane la rmission de tous les paquets stocks
28 Chapitre 1. Etat de lart

partir du paquet considr comme perdu (cest--dire dont le numro


de squence correspond au timer de retransmission).

Selective Repeat : le Selective Repeat est le contrle derreur le plus


complexe mais le plus efficace des mcanismes de contrle derreur.
Contrairement au Go-back-N o la rception dun NACK ou lexpira-
tion dun timer entrane la rmission de toute la fentre de retrans-
mission, un metteur utilisant un Selective Repeat ne retransmet que
les paquets explicitement demands par le rcepteur. Ceci permet de
rduire le nombre de retransmissions inutiles mais accrot la complexit
des entits mettrice et rceptrice. Notons que lentit rceptrice doit
acquitter individuellement chaque paquet et doit mmoriser les paquets
arrivs hors squence.

Une mise en uvre amliore du SR a t propose dans le protocole


TCP via limplmentation du concept de Selective Acknowledgment
(SACK). Par lenvoi dun SACK, lentit rceptrice informe lmetteur
de la rception de tous les paquets reus (y compris donc ceux reus
hors squence). Ainsi, lmetteur ne retransmet que les paquets perdus.

Remarque : les mcanismes de type ARQ entranent une augmentation


non contrle du dlai. De plus, les mcanismes prsents ci-dessus
offrent un service dordre total et de fiabilit totale sur le transfert des don-
nes. En consquence, ces mcanismes peuvent tre incompatibles avec les
besoins temporels et ne prennent pas en compte les besoins dordre et de
fiabilit partiels des applications multimdias.

1.4.4.3 Conclusion

Dvelopper des mcanismes de contrle derreur et de congestion au


niveau Transport plutt quau niveau applicatif offre des avantages en
termes de gnricit et de rduction de la complexit pour les applica-
tions. Cependant, certains mcanismes restent du ressort de lapplication.
Cest le cas de certaines techniques de FEC comme SFEC, dj voqus
prcdemment.
Les mcanismes de contrle de congestion, notamment ceux orients d-
bit, peuvent tre mis en uvre au niveau Transport et permettent dadap-
ter le dbit dmission aux congestions du rseau. Cependant, la stratgie
utilise par les entits mettrices pour rduire le dbit peut prendre plu-
sieurs formes. Elle peut par exemple consister retarder lenvoi de cer-
tains paquets de manire rester conforme un dbit maximal autoris.
Cependant, cette politique peut savrer inadquate pour les applications
multimdias (ou plus gnralement temps rel) qui naccepteraient pas
une augmentation trop importante du dlai de transit.
On peut alors, par exemple, envisager non plus de retarder lenvoi des pa-
quets, mais plutt denvoyer uniquement les paquets les plus prioritaires.
On peut galement modifier la compression ou le codage des donnes
mettre, au cot dune diminution acceptable de la qualit du flux. Ces
mcanismes, naturellement du ressort de lapplication, sont actuellement
1.4. QoS au niveau de la couche Transport 29

mis en uvre dans certaines des applications multimdias utilises dans


lInternet [WU 00].

1.4.5 Mcanismes de Transport pour le multimedia

De nouveaux concepts ont t proposs au niveau Transport pour offrir


une meilleure QoS que celle offerte par les protocoles UDP et TCP, en
tirant parti des caractristiques des flux vhiculs.

1.4.5.1 Contrle de congestion orient QoS

1.4.5.1.1 TFRC TCP-Friendly Rate Control [FLO 08] est un mcanisme de contrle
de dbit linitiative de lmetteur bas sur un modle. Il a t conu pour
minimiser les variations brusques de dbit afin de rpondre aux besoins
des applications multimdias. Il permet galement de respecter les flux
TCP vis--vis de lutilisation de la bande passante.
Lmetteur ajuste le dbit dmission des paquets en fonction des feedback
envoys par le rcepteur. En fonction des informations contenues dans
le feedback, lmetteur calcule le dbit dmission selon la formule 1.2
suivante :
s
TFRC = q q (1.2)
2bp 3bp 2)
R 3 + t RTO ( 3 8 ) p ( 1 + 32p
avec TFRC le dbit en octets/s, s la taille dun paquet en octets, R le RTT
en secondes, t RTO la valeur du timer de retransmission en secondes, p
[0..1] le taux dvnements de pertes calcul par lmetteur, b le nombre
maximal de paquets acquitts par un acquittement TCP. Si aucun feedback
nest reu, lmetteur diminue le dbit dmission par deux.
TFRC rpond donc trois besoins dans le cadre dun mcanisme de trans-
port orients QoS : le respect des flux TCP (TCP-Friendliness), la mini-
misation des variations brusques de dbit et lindpendance vis--vis du
contrle derreur. Cependant, la politique mise en uvre pour respecter
le dbit dmission autoris consiste retarder lenvoi des paquets (sans
distinction de ces paquets), ce qui peut poser certains problmes vis--vis
des contraintes de dlai des applications multimdias.

1.4.5.1.2 Contrle de congestion bas sur TFRC et orient QoS. Afin de ne pas
pnaliser les applications ayant des contraintes de dlai strictes, une so-
lution propose dans [EXP 03a] consiste ne pas systmatiquement re-
tarder lenvoi des paquets, mais choisir les paquets envoyer prio-
ritairement. Cela suppose que la couche Transport puisse rcuprer une
description du flux applicatif transfrer lui permettant den dduire la
priorit des paquets le composant. Le choix denvoyer ou non un paquet
peut se faire galement aprs avoir estim, grce au RTT et au temps inter-
paquets, la date de rception du paquet. Si la date de rception dpasse un
dlai acceptable, le paquet peut tre considr par lapplication rceptrice
comme obsolte.
30 Chapitre 1. Etat de lart

En sinspirant de la technique dabonnement par couches dans le contexte


du multicast au niveau IP, ce mcanisme de rejet de paquets en mission
a t propos pour les flux MPEG composs de trois types dimages : I, B,
et P.
Il dfinit 3 niveaux (par exemple) de qualit :
Couche 2 : images I, P et B ;
Couche 1 : images I et P seulement ;
Couche 0 : images I seulement.

En fonction de lestimation de la date de rception des paquets, lmetteur


adapte son dbit dmission en sabonnant la couche adquate, cest-
-dire en envoyant les paquets en fonction de leur priorit.

1.4.5.2 Contrles derreur orients QoS

Les mcanismes de contrle derreur ont fait lobjet de nombreux travaux,


visant en amliorer les performances ou en tendre les fonctionnalits.

1.4.5.2.1 Contrle derreur garantie dordre et fiabilit partiels Alors que les
protocoles usuels noffrent soit aucune garantie dordre ou de fiabilit sur
le transfert des donnes utilisateur (UDP), soit une garantie dordre total et
de fiabilit (TCP), les nouvelles applications (en particulier multimdias)
prsentent des besoins exprimables en termes de fiabilit partielle (des
pertes sont parfois tolrables) et dordre partiel (les donnes peuvent tre
remises lapplication rceptrice dans un ordre non plus total ou nul, mais
partiel, correspondant au besoin en synchronisation des flux manipuls -
audio et vido par exemple).
Face cette lacune, un nouveau concept de protocole a t introduit, les
protocoles ordre et fiabilit partiels [AME 94], permettant doffrir tous
les services partiellement ordonns et partiellement fiables, en fonction
des besoins des applications (Figure 1.2).

Figure 1.2 Espace des protocoles ordre et de fiabilit partiels

Deux principaux avantages dcoulent de cette proposition : [OWE 98]


montre que lutilisation de ces protocoles permet :
doptimiser lutilisation des ressources du rseau et
de minimiser le dlai de transit des paquets tout en respectant les
1.4. QoS au niveau de la couche Transport 31

contraintes de fiabilit et de synchronisation logique (ordre partiel) in-


hrentes au transfert de documents multimdias.

1.4.5.2.2 Fiabilit partielle diffrencie et temporise Le concept de fiabilit par-


tielle diffrencie [EXP 03a] est bas sur la notion de couche introduite
prcdemment. La retransmission dun paquet est effectue sur la base des
contraintes de fiabilit partielle de lapplication rceptrice. Cependant, elle
est galement couple un mcanisme prenant en compte les contraintes
de dlai, qui peut tre mis en uvre soit au niveau de lmetteur soit au
niveau du rcepteur.
Approche metteur : lorsque lmetteur constate la perte dun paquet, il ef-
fectue la retransmission seulement sil constate que cette perte nest pas
acceptable au regard des besoins en fiabilit partielle de lapplication r-
ceptrice. Il doit galement prendre en compte le fait que le paquet retrans-
mis doit arriver destination avant dtre considr comme obsolte ;
Approche rcepteur : le rcepteur peut lui-mme demander explicitement
la retransmission dun paquet en fonction de ses besoins en fiabilit par-
tielle et de ses contraintes de temps. Cependant, il peut tre plus difficile
pour le rcepteur de dterminer quels sont les paquets quil souhaite re-
cevoir en priorit ou ce quil veut obligatoirement recevoir. Cela suppose
quil connaisse la structure du flux, ce qui nest pas toujours possible, par
exemple dans le cas des flux MPEG ou H263.

1.4.6 Gestion cooprative de la QoS

En parallle des travaux prcdents, dautres travaux ont abord le pro-


blme de la QoS Transport sous un angle coopratif.
Introduit dans [CHA 96] et tendu dans [OWE 98], puis plus rcemment
dans [HEI 03], un concept important est celui de multi-connexion (MC).
Une MC permet son utilisateur de grer plusieurs connexions (chacune
ddie un flux spcifique) entre deux utilisateurs de faon non indpen-
dante. Par exemple, deux connexions dune mme MC (une pour laudio,
une pour la vido) peuvent tre dgrades de faon diffrente lorsque elles
ont ragir une congestion du rseau.
La figure Figure 1.3 illustre les principes darchitecture dune multi-
connexion de niveau Transport ordre et fiabilit partiels la fois intra
et inter-flux tel que propose dans [CHA 96].

Figure 1.3 Architecture dun Transport multimdia connexions dordre partiel


32 Chapitre 1. Etat de lart

Larchitecture propose est compose de trois connexions de Transport


ordre et fiabilit partiels (POC : Partial Order Connection), fournissant
chacune une QoS rpondant aux caractristiques du flux transport (texte,
audio et vido par exemple).
A la diffrence des approches classiques, les trois connexions sont coor-
donnes entre elles pour prserver les relations de synchronisation lo-
giques existant entre les flux vhiculs (texte synchronis en sous titre
de laudio par exemple, lui mme synchronis avec la vido).
La coordination est envisage par le biais de deux paramtres : lordre
partiel et la fiabilit partielle.
La gestion de lordre partiel se situe non seulement au travers de chaque
connexion, mais galement entre ces connexions. En cela, elle permet de
prendre en compte les contraintes de synchronisation logique la fois
intra et inter-flux de lapplication. Une telle architecture permet ainsi de
mettre en uvre le service dordre partiel multimdia le plus adapt aux
contraintes de synchronisation logique (cest--dire hors aspect temporel)
de lapplication.
Lintgration de la notion de fiabilit partielle repose sur un mcanisme
de contrle des pertes pouvant tre mis en uvre soit connexion par
connexion , soit par groupe de connexions . Lobjectif de chacun de
ces mcanismes est de permettre la remise au plus tt dune donne non
dlivrable au regard de lordre partiel (intra et inter-flux), au prix de
la dclaration de perte de la(des) donne(s) qui la prcde(nt) dans lordre
partiel. La dclaration de perte doit respecter la composante fiabilit
de la QoS requise sur chaque connexion.
Notons galement les travaux suivants :
[BAL 01] propose une solution pour traiter le problme du contrle de
congestion pour des agrgats de flux, grce au congestion manager (CM)
qui permet de multiplexer plusieurs flux dune application qui partagent
le mme chemin.
[OTT 07] aborde le problme de la coordination de flux pour les appli-
cations multimdias. Il propose pour cela un protocole permettant aux
applications dobtenir des informations sur ltat du rseau et notamment
concernant la bande passante. Les applications sont ensuite libres dappli-
quer leur propre schma de coordination en fonction de leur besoin.

Conclusion du chapitre

Lobjet de ce chapitre tait de prsenter le panorama des solutions de ges-


tion de la QoS dans lInternet et dy positionner nos travaux. Nous avons
dabord motiv ces solutions en explicitant les besoins applicatifs, issus en
particulier des volutions des applications, aujourdhui multimdias (au-
dio, vido, texte) et distribues dans le cadre dactivits potentiellement
complexes, telles que les activits cooprative de groupe.
Les diffrentes solutions prsentes ont t classes en deux approches :
1.4. QoS au niveau de la couche Transport 33

lune base rservation pour la garantie de la QoS, et lautre base adap-


tation pour loptimisation de la QoS. La premire approche suppose une
relative stabilit des ressources du rseau, et trouve son contexte dappli-
cation dans lInternet classique, multi-oprateurs (autrement appel multi-
domaines), bas sur une infrastructure de rseaux essentiellement filaires.
Cette hypothse peut cependant tre remise en cause dans des contextes
de rseaux amens se dvelopper dans le futur, typiquement mobiles,
sans fil, ad-hoc, connects ou non lInternet ; dans de tels contextes, des
ressources rserves un instant donn peuvent ne plus tre disponibles
un autre instant : lapproche base rservation doit alors tre complte,
voire remplace par une approche visant optimiser la QoS en adaptant le
systme de communication aux variations du contexte. Ce besoin est ren-
forc si lon considre des contextes dapplications non indpendantes o
lon souhaite, pendant lexcution, accorder des priorits certaines ap-
plications par rapport dautres en fonction des performances courantes
du rseau et des prfrences des utilisateurs.
Nos travaux sinscrivent dans cette deuxime approche et visent plus sp-
cifiquement contribuer au dveloppement de protocoles de Transport
auto-configurables, aptes rpondre aux besoins en QoS dapplications
non indpendantes distribues dans des rseaux ne permettant pas ou
noffrant pas la possibilit de garantir une QoS. Ladaptation cible touche
les mcanismes locaux ou distribus du protocole quil sagit in fine de
pouvoir paramtrer, voire remplacer, dynamiquement.
Les problmes rsoudre pour mettre en uvre une telle auto-adaptation
ont t noncs dans ce chapitre. Nous en avons trait certains dans
le cadre des travaux prsents dans ce mmoire, qui sont noncs ci-
dessous :
le premier problme consiste dfinir larchitecture de mcanismes lo-
caux ou distribus ncessaires au contrle de ladaptation. Le chapitre
2 prsente notre proposition darchitecture, dveloppe dans le cadre
du projet NETQoS, en sinspirant notamment des solutions de gestion
de rseau base politique, prsentes en section 1.3.2. La rsistance au
facteur dchelle de cette architecture est considre dans le chapitre 4,
ddies la simulation et aux mesures de performances ;
le second problme concerne les actions dadaptation cibles. Les
mcanismes de gestion de la QoS au niveau Transport, comme le
contrle de congestion et le contrle derreur, ont t dcrits dans ce
chapitre. Partant de certains de ces mcanismes, notre deuxime contri-
bution propose une gestion cooprative de la bande passante pour des
connexions de niveau Transport non indpendantes, impliques dans
un contexte dactivits coopratives de groupe telles que les oprations
dintervention durgence (OIU). Un modle doptimisation de la rpar-
tition de la bande passante est propos au chapitre 3 ; lvaluation des
bnfices et des limites de ce modle est prsente au chapitre 4.
Principes darchitecture
dun systme de gestion
auto-adaptative de la QoS
2

Sommaire
2.1 Besoins des acteurs du systme NETQOS . . . . . . . . . . . 37
2.1.1 Dfinition des acteurs . . . . . . . . . . . . . . . . . . . . . 37
2.1.2 Besoins des utilisateurs et des applications . . . . . . . . . 38
2.2 Description de larchitecture . . . . . . . . . . . . . . . . . . 39
2.2.1 Prsentation gnrale du systme . . . . . . . . . . . . . . 39
2.2.2 Description des services . . . . . . . . . . . . . . . . . . . . 41
2.2.3 Architecture fonctionnelle du systme . . . . . . . . . . . . 43
2.3 Spcification dtaille des composants de lentit APA 49
Choix remarquables de conception
2.3.1 . . . . . . . . . . . . . . 49
Spcification dtaille du PDM . .
2.3.2 . . . . . . . . . . . . . . 54
Spcification dtaille du PAM . .
2.3.3 . . . . . . . . . . . . . . 55
Spcification dtaille du PEM . .
2.3.4 . . . . . . . . . . . . . . 56
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

L e chapitre prcdent a montr que plusieurs solutions doptimisation


ou de garantie de la QoS ont t proposes aux diffrents niveaux de
larchitecture OSI, en particulier aux niveaux Rseau et Transport. Compte
tenu des volutions technologiques actuelles, choisir et adapter de faon
automatique les solutions les plus adquates au regard des contraintes
(ou des capacits) de lenvironnement rseau et des besoins applicatifs est
un enjeu majeur. Faire face ce dfi ncessite cependant de rpondre
plusieurs problmes, qui ont t rsums en conclusion du chapitre 1.
Ce nouveau chapitre prsente notre premire contribution, lie au be-
soin de contrle pour la gestion adaptative de la QoS dans un environ-
nement de rseaux htrognes. Inspire de la gestion de rseau base
politique, la gestion propose repose sur lapplication de politiques adap-
tatives concourant la mise en uvre dactions dadaptation, au niveau
du rseau et des htes (en particulier au niveau Transport), pour loptimi-
sation de la QoS en fonction de lvolution des besoins et des contraintes
du rseau.

35
36 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

Larchitecture propose rsulte dun travail men dans le cadre dun projet
europen, le projet NETQoS, dont lobjectif tait de concevoir un modle
conceptuel pour ladaptation oriente QoS au niveau Rseau et Transport,
indpendant dun environnement rseau spcifique. Nos contributions ont
port dune part sur llaboration de larchitecture du systme NETQoS, et
dautre part de faon plus spcifique, sur llaboration de la structure du
composant central du systme (dnomm par la suite APA pour Automated
Policy Adaptor), charg de concevoir, dadapter et de faire appliquer des
politiques oprationnelles aux entits en charge de la gestion directe de la
QoS, typiquement de niveau Transport (en loccurrence ETP).
La suite de ce chapitre prsente nos contributions en termes darchitec-
ture, modlise en UML, en faisant directement rfrence au projet NET-
QoS. Pour concevoir le systme, nous nous sommes inspirs de mthodes
issues du gnie logiciel. Aprs avoir identifi les acteurs du systme et
leurs besoins, nous construisons une reprsentation oriente fonctionna-
lit par le biais des actions permises par le systme. Il en dcoule une
premire dfinition des composants. Llaboration de diagrammes de s-
quence permet de spcifier les interactions et les messages changs entre
ces composants. Une dmarche itrative conduit ensuite raffiner la struc-
ture des composants, notamment celui de lAPA auquel nous avons plus
spcifiquement contribu.
Ainsi, la section 2.1 identifie les bnficiaires (dnomms acteurs en
UML) du systme NETQoS et leurs besoins. Plus spcifiquement, elle pr-
cise les besoins de deux types dacteurs directement concerns par une
gestion adaptative de la QoS au niveau Transport : les applications et leurs
utilisateurs.
La section 2.2 sintresse au modle darchitecture gnrale de NETQoS :
les principes gnraux du systme et les services offerts (donns sous la
forme de Use Cases UML) sont tout dabord prsents ; les composants
fonctionnels majeurs de larchitecture NETQoS sont dcrits dans un se-
cond temps, ainsi que leurs principales interactions.
Enfin, la dernire partie (section 2.3) dtaille le modle darchitecture du
composant spcifique de notre contribution (lAPA), incluant son applica-
tion la gestion adaptative dentits de Transport configurables, en par-
ticulier celles du framework ETP prsent au chapitre 1. Notons ici que
le modle propos pour lAPA est orient implmentation, sachant que la
dmonstration relle de deux prototypes JAVA du systme NETQoS a t
effectue lors des deux dernires revues du projet.
2.1. Besoins des acteurs du systme NETQOS 37

2.1 Besoins des acteurs du systme NETQOS

Suivant la dmarche voque prcdemment, cette section dcrit les ac-


teurs du systme NETQoS, et prcise leurs besoins.

2.1.1 Dfinition des acteurs

Plusieurs acteurs ont t identifis comme bnficiaires potentiels du sys-


tme NETQOS (figure 2.1). Nos travaux nous ont amens considrer
plus spcifiquement les acteurs "Application" et "Utilisateur", directement
intresss par une adaptation de niveau Transport.

Figure 2.1 Acteurs du systme NETQOS


Lutilisateur est une personne physique utilisant un terminal connect au
systme NETQOS. Il excute depuis son terminal le lancement dapplica-
tions distribues pour laccs distance des donnes ou pour dialoguer
avec dautres personnes. Un utilisateur est le client dun ou plusieurs four-
nisseurs de service.
Lapplication dsigne un programme ou ensemble de programmes dis-
tribus lancs sur le terminal dun utilisateur (vido la demande, vi-
sioconfrence, VoIP, . . .) ou sur un serveur dapplication dun fournisseur
de service (serveur de vido la demande, serveur de travail collabora-
tif, passerelle VoIP, . . .). Une application peut tre consciente du systme
NETQoS et, par exemple, lui communiquer explicitement ses besoins en
QoS lors de son excution. Dans le cas contraire, le systme doit dcouvrir
lexistence de lapplication, et satisfaire ses besoins en QoS de faon trans-
parente pour celle-ci. Lutilisateur ou le fournisseur de service peuvent
exprimer les besoins dune application auprs du systme NETQoS. Nous
avons qualifi le premier type dapplications "NETQoS-Aware" et celles de
second type "NETQoS-Unaware".
Loprateur est une entit responsable de ladministration du rseau. Le
rseau est charg de transporter le trafic gnr par les applications utili-
ses par le fournisseur de service ou les utilisateurs.
Le fournisseur de service est une entit offrant des services aux utilisateurs
en utilisant le rseau de loprateur. Par exemple, une entreprise offrant
un service de Vido la demande ou un fournisseur de passerelle VoIP
38 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

autorisant les utilisateurs appeler des lignes du Rseau Tlphonique


Commut (RTC) depuis leurs terminaux.
La section suivante prsente les besoins de deux de ces acteurs, les acteurs
"utilisateur" et "application", directement concerns par une adaptation
oriente QoS de niveau Transport. Ces besoins sont rappels succincte-
ment, car ils ont dj t en partie dtaills dans ltat de lart (section
1.1).
Les besoins en QoS de loprateur et du fournisseur de service relvent
davantage de solutions de niveau Rseau et ne seront pas dcrites dans ce
manuscrit.

2.1.2 Besoins des utilisateurs et des applications

Utilisateur

Lutilisateur doit pouvoir exprimer ses besoins en QoS auprs du systme


NETQoS en des termes simples de son point de vue, par le biais dune
interface graphique qui lui masque la complexit technique du systme
sous-jacent. Il peut ajouter, modifier, supprimer des prfrences concer-
nant ses besoins. Par exemple, lutilisateur peut spcifier quelles applica-
tions sont les plus importantes de son point de vue. Il peut aussi spcifier
ce quil souhaite voir se passer en termes de dgradation de qualit lors-
quil passe dun rseau daccs filaire un rseau sans fil.
Un exemple de prfrence peut tre : "En temps normal, je veux pouvoir
tlphoner avec une qualit comparable un tlphone portable. En re-
vanche, lorsque je parle avec une personne dans le cadre professionnel, la
qualit doit tre aussi bonne que lorsque je tlphone depuis un tlphone
fixe".
Pour une mme application, lutilisateur peut galement exprimer des
priorits ou une importance relative entre les diffrents flux. Pour une ap-
plication de travail collaboratif incluant VoIP et tableau blanc, lutilisateur
peut par exemple exprimer quil prfre entendre correctement son inter-
locuteur, mme sil existe un certain dlai pour la mise jour du tableau,
qui a moins dimportance.
Outre le besoin dexprimer ses prfrences, lutilisateur doit tre inform
des services offerts par le systme, de la QoS effectivement fournie ainsi
que des informations de facturation.

Application

Les besoins des applications peuvent tre exprims en termes de para-


mtres de QoS de base ou en des termes plus volus. Rappelons que la
recommandation de lITU [ITU01] et [REC 02] dfinit des paramtres de
QoS de base par :
IPTD (IP Packet Transfert Delay) : le dlai de transfert dun paquet ;
2.2. Description de larchitecture 39

IPDV (IP Packet Delay Variation) : la variation du dlai entre deux


paquets conscutifs ;

IPLR (IP Packet Loss Ratio) : le rapport entre le nombre de paquets


perdus sur lensemble des paquets transmis ;

IPER (IP Packet Error Rate) : le rapport entre le nombre de paquets


errons sur le nombre de paquets transmis.

IPPT (IP Packet Throughput) : le dbit requis peut tre un paramtre


important du point de vue de lapplication. Il est gal au nombre total
de paquets IP reus sans erreur sur un intervalle de temps donn.

2.2 Description de larchitecture

Les acteurs du systme et leur besoin ayant t identifis, nous dcrivons


prsent les principes de conception du systme NETQoS.

2.2.1 Prsentation gnrale du systme

Larchitecture conceptuelle du systme NETQoS sinspire du modle


PBNM prsent dans ltat de lart en ceci quelle distingue plusieurs ni-
veaux de politique ; trois niveaux ont t considrs dans NETQoS :
les politiques de plus haut niveau correspondent aux besoins et pr-
frences trs gnraux des acteurs, illustrs par exemple pour lacteur
utilisateur dans la section prcdente ;
les politiques intermdiaires correspondent aux objectifs de QoS rseau
satisfaire pour les applications, enrichis ventuellement par un niveau
de priorit ;
enfin, les politiques oprationnelles correspondent aux choix de ser-
vices, mcanismes et/ou protocoles mis en uvre au niveau des entits
en charge de la communication, par exemple aux niveaux Rseau et
Transport.

Notons dores et dj que lune des fonctionnalits du systme NETQoS


sera lie sa capacit raffiner le plus haut niveau de politiques en poli-
tiques de niveau intermdiaire, puis le niveau intermdiaire en politiques
de niveau oprationnel.
Le second modle architectural dont sinspire le systme NETQoS et le
modle de lAutonomic Computing galement prsent dans ltat de lart.
Etendant ainsi le modle PBNM, le systme NETQoS inclut les fonctions
ncessaires ladaptation des politiques oprationnelles en fonction de
lvolution du contexte, lie dune part la possibilit que les acteurs mo-
difient leur politique de haut niveau, et dautre part un changement
dtat des ressources du rseau. Les fonctions de supervision des poli-
tiques de haut niveau et des performances des politiques oprationnelles,
40 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

et les fonctions dadaptation des politiques oprationnelles sont donc n-


cessaires.
Dans ce positionnement, quatre entits fonctionnelles ont t identifies
pour le systme NETQoS (Figure 2.2). Elles visent permettre aux utili-
sateurs du systme dexprimer leur besoins et celui-ci de les interprter,
den laborer une politique oprationnelle, de la dployer et den valuer
ladquation aux besoins en vue dune rvision si le contexte change.

Figure 2.2 Les entits principales du systme NETQoS

Ces quatre entits, dont les interactions seront dcrites ultrieurement,


sont les suivantes :
lentit de description des politiques (Policy Description - POLD) repr-
sente un ensemble dontologies utilises pour spcifier les politiques de
niveau acteurs

lentit de gestion des prfrences des utilisateurs (Actor Preference


Manager - APM) est destine fournir chaque utilisateur du systme
NETQoS une API sous la forme dune interface graphique (GUI) lui
permettant de dfinir des politiques dynamiques bases sur des on-
tologies. Ces politiques (besoins, prfrences, profils, . . .) peuvent tre
exprimes avant ou pendant la communication.

lentit de gestion de ladaptation (Automated Policy Adaptor - APA)


est lentit centrale du systme de communication. Sa fonction est de
dcider des politiques oprationnelles dployer (notamment au niveau
Transport) pour permettre au systme de communication de fournir
une QoS optimise en tenant compte des politiques dynamiques des
acteurs, exprimes via lAPM et de lvolution des performances du
rseau.

le module de supervision et danalyse/mesure (Monitoring and Mea-


surement - MoMe) est charg dobserver et de mesurer lvolution du
contexte applicatif et rseau (changement des besoins utilisateurs, chan-
2.2. Description de larchitecture 41

gement des ressources dextrmit ou, . . .). Il doit galement valuer


lefficacit des politiques oprationnelles.

2.2.2 Description des services

Pour aboutir larchitecture de mise en uvre de ces entits fonction-


nelles, diffrents cas dutilisation (Use Case UML) du systme ont t
dfinis. Ils permettent dillustrer les services fournis aux acteurs prsen-
ts prcdemment. Ces cas dutilisation sont dcrits avec les diagrammes
UML adquats. A titre dexemple, un Use Case caractristique est dtaill
sous la forme dun Use Case textuel. Les autres cas dutilisation textuels
sont dcrits dans le dlivrable [CHA 07d].

Figure 2.3 Use Cases du systme NETQoS

2.2.2.1 Classification des Use Cases

Les cas dutilisation sont classs selon trois catgories correspondant aux
trois types de services offerts par le systme NETQoS (Figure 2.3) :
services S1 : Dfinir les politiques des acteurs
services S2 : Superviser la QoS sans perturber le fonctionnement des
applications de faon non intrusive
services S3 : Satisfaire les politiques des acteurs en adaptant les pro-
42 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

tocoles Transport et en configurant les dispositifs rseaux comme les


routeurs notamment.
Nos contributions ont clairement concern les services de type S3.
La figure 2.3 illustre lensemble des Use Cases. On y voit par exemple
quun utilisateur peut interagir avec le systme, notamment en dfinissant
ses prfrences dutilisation (exprimer des priorits sur des applications,
sur des flux, etc. . .), en obtenant des informations de supervision ou en
obtenant la QoS quil souhaite pour une application.

Figure 2.4 Use Case du service S3 : Satisfaire les politiques des acteurs

La figure 2.4 illustre tous les Use Cases relatifs aux services dlaboration
et de mise en uvre des politiques oprationnelles (S3). Nos contributions
au projet se situant directement ce niveau, nous dtaillons ci-aprs lun
de ces services visant satisfaire la politique dun utilisateur excutant
une application NETQoS-Unaware.

2.2.2.2 Exemple dtaill : Use Case S3/1, associ la satisfaction dune politique
utilisateur pour une application "NETQoS-Unaware"

Le Use Case dcrit titre dexemple dans cette section illustre la prise
en compte dune politique utilisateur pour une application NETQoS-
unaware, non avertie de lexistence du systme NETQoS.
Ce Use Case permet en particulier dintroduire le rle de lentit de gestion
de ladaptation (APA) laquelle nous avons plus spcifiquement contri-
bu. Pour les besoins de la description qui suit, notons ds prsent que
lAPA contient trois blocs fonctionnels qui seront dtaills dans la suite
du chapitre (section 2.2.3.2.2) : le gestionnaire du provisionnement initial
2.2. Description de larchitecture 43

des politiques, appel Policy Decision Manager (PDM), le gestionnaire de


ladaptation des politiques ou Policy Adaptation Manager (PAM), et le
gestionnaire de lapplication de ces politiques auprs des entits gres,
appel Policy Enforcement Manager (PEM).
Le diagramme de squence de ce Use Case est reprsent sur la figure 2.5.
Lacteur de ce Use Case est un utilisateur qui excute une application
NETQoS-Unaware. Cet utilisateur est sens avoir dj fourni au systme
NETQoS une expression de la politique quil souhaite voir appliquer pour
cette application dans le cadre de linvocation dun service relevant du ser-
vice S1. Cette politique de haut niveau est accessible dans un rpertoire de
stockage des politiques. Le systme NETQoS doit alors dynamiquement
(cest--dire au lancement de lapplication) raliser les actions ncessaires
au niveau des entits de communication gres (relevant des couches R-
seau et Transport) pour satisfaire les besoins/prfrences de cet utilisateur.
Les numros dans le texte du paragraphe ci-dessous correspondent ceux
prsents sur le diagramme de squence de la figure 2.5.
Quand un utilisateur lance une application NETQoS-Unaware (1), le ges-
tionnaire de contexte (CM pour Context Manager, qui est une partie lo-
gique du MoMe) dtecte lvnement (2) et informe le gestionnaire de pro-
visionnement des politiques (PDM) de lAPA (3). Le PDM rcupre alors
la politique dfinie par lutilisateur pour lapplication identifie (4). En se
basant sur ces besoins, le PDM labore un premier ensemble de politiques
oprationnelles permettant de prendre en compte la politique utilisateur
(5). Une fois le provisionnement effectu, le transfert de donnes peut
commencer (6). Pendant le transfert, le gestionnaire de supervision des
politiques (MoMe) monitore en continue la QoS fournie et informe lAPA
en cas de non respect des paramtres requis (7). En fonction de la QoS
mesure, le gestionnaire dadaptation des politiques de lAPA (PAM) peut
dclencher des mcanismes dadaptation et des changements de politiques
oprationnelles labores lors de la phase de provisionnement initial (8).
Nous prsentons maintenant larchitecture fonctionnelle du systme NET-
QoS, btie sur les bases de lensemble des Use Cases dfinis au pralable.

2.2.3 Architecture fonctionnelle du systme

2.2.3.1 Diagramme de structure gnrale

Tel quintroduit prcdemment, le systme NETQoS est compos de


quatre entits fonctionnelles principales interagissant de manire logique
selon le diagramme de structure illustr figure 2.6.
Cette section prsente en dtail les fonctionnalits de lentit APA sur la-
quelle ont port nos contributions spcifiques larchitecture du systme
NETQoS.
44 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

Figure 2.5 Use Case S3/1 : Satisfaire une politique utilisateur excutant une applica-
tion NETQoS-Unaware

2.2.3.2 Lentit APA

Le rle de lentit APA est de raliser le processus de provisionnement


et dadaptation de politique, cest--dire llaboration et ladaptation des
2.2. Description de larchitecture 45

Figure 2.6 Diagramme de structure composite de NetQoS

politiques oprationnelles appliquer une ou plusieurs couches du sys-


tme de communication dans le but de satisfaire les politiques de niveau
acteur en tenant compte de lvolution du contexte.

2.2.3.2.1 Les fonctions de lentit APA

Provisionnement de politique
Telle que dfinie dans le projet NETQoS, la notion de provisionnement
(incluant le re-provisionnement) relve dune problmatique dadaptation
architecturale, cest--dire lie au choix de la composition mcanismes
mettre en uvre pour satisfaire une politique de niveau acteur. Cette
phase est ncessaire au dmarrage des communications, mais peut gale-
ment intervenir en cours de communication si ncessaire.
En tenant compte des objectifs de politique oriente-rseau (objectifs de
QoS), des informations de contexte (rseau daccs) et des informations
issues de mesures (taux de pertes observ sur un chemin donn de bout-
en-bout) effectues par lentit de monitoring (MoMe), lAPA doit dfinir
la politique oprationnelle qui permet de raliser les objectifs de QoS.
Cette politique oprationnelle est compose de rgles de configuration
aux diffrents niveaux de la pile de communication, notamment de niveau
Rseau et Transport. Par exemple :
au niveau Rseau, ces rgles peuvent dfinir le type de classes de ser-
vice qui pourraient tre appliques quand des services diffrencis sont
disponibles ; dans ce cas, le SLA contract avec lacteur doit aussi tre
pris en compte dans le processus de dcision.
au niveau Transport, ces rgles dfinissent le choix de composition de
diffrents mcanismes qui seront implments dans le protocole de
46 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

Transport sous-tendant la communication considre ; par exemple, la


composition dun contrle de congestion bas dbit tel que TFRC, et
dun contrle des pertes fiabilit partielle temporise peut tre dci-
de pour rpondre aux besoins en QoS dune application multimdia
de type streaming vido.
Le provisionnement de politique est ralis :
quand la politique doit tre active pour la premire fois, cest--dire
lorsquune nouvelle application est lance ;
ou lorsquune politique oprationnelle active doit tre redfinie, en rai-
son de changement de conditions. Par exemple si le contexte change
pendant la communication (changement de rseau daccs, changement
dobjectifs de QoS, . . .), alors lAPA peut avoir revoir les rgles de
configuration existantes, un ou plusieurs niveaux dentits gres.

Adaptation de politique
Dans NETQoS, la notion dadaptation de politique traite de laspect com-
portemental du processus dadaptation. Celui-ci agit sur une politique
oprationnelle active et conduit la modification de la valeur des para-
mtres des services et des mcanismes slectionns. Cependant larchitec-
ture de ces services et mcanismes nest pas change, cest--dire que le
choix de composition reste le mme. Par exemple :
Au niveau Rseau, le changement de paramtres dun service bas AF
est un exemple daction dadaptation.
Au niveau Transport, la modification du dbit dmission dune entit
de Transport donne est un autre exemple daction dadaptation.

Une adaptation de politique intervient lorsquune politique oprationnelle


doit tre adapte en raison de changement de conditions. Par exemple, si
le critre de succs qui dfinit la politique nest pas respect, alors lAPA
peut essayer dadapter un ou plusieurs niveaux dentits gres. Si ladap-
tation comportementale savre insuffisante, le choix de composition des
services/mcanismes sera reconsidrer dans le cadre dun nouveau pro-
visionnement de politique en remplacement de celle existante.

2.2.3.2.2 Les blocs fonctionnels de lAPA

Pour implmenter les fonctions de provisionnement/adaptation, lAPA


contient trois blocs fonctionnels (Figure 2.7) :
le Policy Decision Manager (PDM) est charg de dcider des politiques
oprationnelles qui permettent de prendre en compte lensemble des
politiques de niveau acteur en fonction des informations de contexte ;
le Policy Enforcement Manager (PEM) est charg de faire appliquer
les politiques oprationnelles labores par le PDM vers les points de
dploiement de niveau Rseau/Transport (typiquement des entits de
type ETP pour la gestion dun protocole de Transport configurable) ;
le Policy Adaptation Manager (PAM) est charg de ladaptation (com-
portementale) de politique, individuellement ou par sous-ensembles,
quand le critre de succs associ la politique nest pas rempli.
2.2. Description de larchitecture 47

Figure 2.7 Diagramme de structure composite de lAPA

Nous dtaillons prsent ces trois composants de lAPA.

Policy Decision Manager


Partant des objectifs de QoS dfinis pour lapplication et des prfrences
des acteurs, le PDM a pour rle de dcider dun ensemble de politiques
oprationnelles mettre en uvre aux niveaux dadaptation considrs
(par exemple, niveaux Rseau et/ou Transport). Ce raffinement de poli-
tiques peut tre ralis en utilisant des rgles de mise en correspondance
qui tiennent compte de la dynamicit des politiques acteurs et des in-
formations de contexte. Ce raffinement peut conduire des conflits de
politiques (par exemple quand les politiques de niveau acteur ne peuvent
pas toutes tre satisfaites) que le systme doit rsoudre. Dans NETQoS,
la gestion des conflits de politique est particulirement tudie au niveau
Rseau, en tenant compte du SLA ngoci au niveau IP. Elle sort du cadre
de nos contributions.
Les niveaux de politiques oprationnelles peuvent tre traits de manire
spare (gestion de la politique dadaptation un seul niveau) ou en-
semble (gestion de la politique dadaptation plusieurs niveaux) :
dans le cas dune adaptation mono-niveau, le PDM est charg de dcider
des politiques soit au niveau Rseau, soit au niveau Transport ;
dans le cas dune adaptation multi-niveaux, le PDM doit dcider des
politiques impliquant plusieurs niveaux, conscutivement ou simulta-
nment. Dans ce cas, le PDM doit coordonner les actions appliquer
au niveau Rseau et Transport.

Le PDM est activ dans diffrentes situations. Lorsque le contexte a t


48 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

modifi (un acteur a chang sa politique), le PDM dcide de changer


une ou plusieurs de ses politiques oprationnelles. Les modifications de
contexte sont signales au PDM par le Context Manager de lentit MoMe.
De mme, lorsquune politique est value comme tant inefficace, le PDM
peut dcider de la modifier. Il peut aussi reconsidrer un sous-ensemble
de politiques ; les informations relatives linefficacit dune politique sont
fournies au PDM par le PAM. Enfin, lorsquune politique ne peut pas tre
dploye, le PDM est charg de dcider dune nouvelle politique ; il peut
aussi changer des politiques existantes ; les informations relatives lim-
possibilit de dploiement sont fournies au PDM par le PEM.
Chaque fois que le PDM dcide dune (nouvelle) politique oprationnelle,
il fournit les rgles correspondantes au PEM. Si la politique est dployable,
le PDM informe le PAM du dploiement de la nouvelle politique.

Policy Enforcement Manager


Le PEM est charg de faire appliquer les politiques oprationnelles dci-
des par le PDM vers les entits gres. Par exemple :
Pour une politique de niveau Rseau, le PEM distribue les rgles mettre
en uvre par les quipements rseau. Ces quipements dpendent du
type de rseau sous-jacent et peuvent tre par exemple des routeurs de
bordure, des Bandwidth Broker, ou encore outils de gestion de rseau).
Le PEM doit transmettre au PDM un message de succs ou dchec sur
la politique dployer (par exemple, un rseau base sur un principe
de rservation de ressources peut ne pas pouvoir appliquer la politique
requise en raison dune pnurie de ressources) ;
Pour une politique de niveau Transport, le PEM distribue les rgles de
configuration du protocole de Transport appliquer sur les htes dex-
trmits. Par exemple, le dploiement dune politique peut consister
donner des rgles de composition des mcanismes Transport ; dans ce cas,
tous les mcanismes sont senss tre disponibles sur les htes concerns
ou rcuprables par ceux-ci.
Le PEM se veut indpendant des technologies Rseau et Transport qui
sont utilises pour mettre en uvre les politiques ; autrement dit, le PEM
fournit les rgles appliquer dans un langage indpendant de celui utilis
par le systme de communication gr.
En consquence, le PEM fournit des interfaces gnriques permettant la
communication avec les entits gres, et des adaptateurs (appels Agent
dans NETQoS) doivent tre implments, pour traduire les rgles gn-
riques du PEM en des rgles spcifiques une technologie particulire.
La section 2.3.4 de ce chapitre illustre comment nous avons instanci le
concept dagent pour ladaptation au niveau Transport.
Le PEM est activ dans diffrentes situations. Lorsquune (nouvelle) po-
litique doit tre applique, le PEM doit fournir les rgles donnes par le
PDM aux composants du systme de communication. Lorsque les rgles
de politique ne peuvent pas tre appliques (par exemple, si une rserva-
tion de ressources ne peut pas tre faite), le PEM doit informer les PDM
2.3. Spcification dtaille des composants de lentit APA 49

que sa politique ne peut pas tre active. Limpossibilit de dploiement


est notifie au PEM par le systme de communication.

Policy Adaptation Manager


Le PAM est charg de ladaptation comportementale dune politique
lorsque son critre de succs nest pas satisfait. Grce des alarmes en-
voyes par le MoMe, signalant la violation dun critre de succs, le PAM
dcide des paramtres modifier dans la politique oprationnelle exis-
tante. Quand ladaptation souhaite nest pas possible, le PDM est inform
de lchec, en vue dune re-provisionnement de politique. Si ladaptation
est possible, le PAM la fait appliquer par lintermdiaire du PEM.
Le PAM est activ dans diffrentes situations. Lorsque le PAM est inform
par le PDM quune nouvelle politique est mise en uvre, le PAM stocke la
politique dans le rpertoire de politiques oprationnelles avec des critres
de succs (par exemple, le taux de pertes de bout-en-bout doit tre inf-
rieur 5%) et souscrire aux tches de monitoring associes, ralises par
le MoMe. Lorsque le PAM reoit une alarme du MoMe, il essaye dadapter
la politique dfectueuse.

2.3 Spcification dtaille des composants de lentit


APA

Cette section prsente la conception fonctionnelle dtaille des compo-


sants de lAPA.
La section 2.3.1 prsente les choix remarquables de cette conception et
deux cas dutilisation sont prsents pour illustrer les interactions entre
les principaux composants de lAPA.
Les sections 2.3.2, 2.3.3 et 2.3.4 dtaillent ensuite la structure dimplmen-
tation des diffrents composants de lAPA. Les interactions entre ces com-
posants, leurs sous-composants et les autres composants du systme NET-
QoS, sont illustrs travers les deux cas dutilisation prsents dans la
prcdente section.

2.3.1 Choix remarquables de conception

2.3.1.1 APA multi-niveaux ou mono-niveau

La structure de lAPA a t conue de manire pouvoir fonctionner un


seul niveau du systme de communication (par exemple au niveau Trans-
port ou au niveau Rseau) ou plusieurs niveaux (par exemple au niveau
Rseau et au niveau Transport). Lobjectif est de permettre limplmenta-
tion de lAPA en considrant des points de vue indpendants (point de
vue de loprateur et point de vue de lutilisateur), tout en gardant la pos-
sibilit de considrer un point de vue plus global, en combinant plusieurs
niveaux dadaptation ensembles.
50 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

Quand plusieurs niveaux sont impliqus dans le processus dadapta-


tion/provisionnement, deux approches ont t considres pour NET-
QoS :
dans la premire approche, le processus est ralis niveau par niveau :
pour le provisionnement (fonction du PDM), la dcision prise un
niveau donn i dpend de celle prise au niveau i-1 ; par exemple, au-
dessus dun service IP orient DiffServ, le protocole de Transport
composer dpendra des performances fournies par la classe de ser-
vice IP slectionne.
pour ladaptation, on essaye dadapter dabord au niveau le plus
haut, puis aux niveaux sous-jacents par ordre dcroissant, si ladapta-
tion nest pas possible. A chaque niveau, on essaye dadapter dabord
les paramtres des entits gres (grce au PAM) ; si ce nest pas
possible, une adaptation architecturale est ensuite considre (via le
PDM) ;

dans la seconde approche, qui sort du cadre des travaux prsents dans
ce mmoire, le processus de provisionnement et dadaptation est ralis
en considrant plusieurs niveaux ensembles. Lobjectif est de trouver la
meilleure configuration qui, lchelle de plusieurs niveaux du systme
de communication, permet de satisfaire les besoins de la politique.

2.3.1.2 Indpendance de lAPA vis--vis des moteurs de dcision

La structure interne de lAPA a t conue de faon permettre lintgra-


tion de diffrents types de moteur de dcision pour le provisionnement
ou ladaptation. Par exemple, ces moteurs peuvent tre implments avec
des rgles bases sur des canevas (au sens template) ou bases sur des
modles (modle doptimisation par exemple) ; ils peuvent tre appliqus
par niveau de faon indpendante, ou en combinant plusieurs niveaux
ensembles, dune manire cordonne. De faon analogue, lAPA se veut
indpendant du type dentit gre, et doit par exemple pouvoir agir sur
des entits de niveau Transport ou des entits de niveau Rseau ou les
deux.
Pour garder cette indpendance, PDM, PAM et PEM utilisent des compo-
sants que nous avons appels Decisioner, Adapter et Enforcer, qui peuvent
tre implments librement (Figure 2.8). La seule obligation pour ces com-
posants est dimplmenter les interfaces JAVA suivantes :
IPolicyDecisioner est linterface qui doit tre implmente par
les Decisioner ; elle est compose dune seule mthode, takeDeci-
sion(OpPolicy) :OpPolicy, qui retourne la politique oprationnelle
appliquer au niveau i considr. En entre, elle prend la politique
oprationnelle qui a t dfinie au niveau i-1 ;
IPolicyAdapter est linterface qui doit tre implmente par les Adap-
ter ; elle est compose dune seule mthode adaptPolicy(OpPolicy) :boo-
lean, qui retourne un boolen selon que la politique oprationnelle ap-
plique au niveau considr peut tre adapte ou non.
IPolicyEnforcer est linterface qui doit tre implmente par les Enfor-
2.3. Spcification dtaille des composants de lentit APA 51

Figure 2.8 Diagramme de classe de lAPA

cer ; elle est compose dune seule mthode enforcePolicy(OpPolicy).

Ainsi, quel que soit le type de moteurs pour le provisionnement, ladapta-


tion ou la distribution, les codes du PDM, du PAM et du PEM ne changent
pas puisquils utilisent toujours les mmes mthodes pour invoquer les
fonctionnalits des Decisioner, Adapter et Enforcer.

2.3.1.3 Autres choix remarquables

La figure 2.8 montre une autre classe interne APA : Op_REPO qui est un
rpertoire local o sont stockes les politiques oprationnelles. Il est utilis
pour stocker les dcisions du PDM/PAM et pour les rcuprer quand une
adaptation est requise.
La figure 2.9 montre les autres classes utilises dans la conception dtaille
de lAPA :
la classe LaunchEvent identifie un vnement de lancement dune ap-
plication ;
la classe PolViolationEvent identifie une violation de politique pour une
application ;
52 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

Figure 2.9 Autre classes du package APA

la classe (intermediate) Policy inclut plusieurs paramtres, notamment


les paramtres de QoS (dbit, dlai, taux de pertes, gigue) requis pour
une connexion ;
la classe OpPolicy inclut les dcisions dadaptation/provisionnement
du PAM/PDM associes une connexion identifie.

2.3.1.4 Scnarios dapplication de lentit APA

Cette section dtaille deux cas dutilisation de lAPA lis 1) au lancement


dune application et 2) la violation de la politique requise pour une
application.

Use Case 1 : Lancement dune application

Ce Use Case illustre la rponse des composants de lAPA aprs une noti-
fication de lancement dune nouvelle application. Il inclut deux acteurs :
le gestionnaire de contexte (CM), qui notifie cet vnement lAPA via
le PDM, et les agents ( un ou plusieurs niveaux) qui sont notifis par
lAPA (via le PEM) des politiques oprationnelles dployer par les enti-
ts gres. Deux niveaux conscutifs de provisionnement sont considrs
(Rseau puis Transport). La Figure 2.10 fournit une vue de haut niveau du
diagramme de squence impliquant les composants de lAPA et les autres
composants du systme.
Lorsque le CM notifie le PDM dun lancement dune application, ce der-
nier rcupre auprs du rpertoire (REPO) les politiques associes lv-
2.3. Spcification dtaille des composants de lentit APA 53

nement. Une fois les politiques rcupres, le PDM invoque les dcideurs
(decisioner) de niveau Rseau et/ou Transport, rcupre auprs deux les
politiques oprationnelles mettre en uvre et les transmet au PEM pour
quelles soient appliques. Les politiques sont galement stockes dans le
rpertoire de stockage des politiques oprationnelles.

Figure 2.10 Diagramme de squence dun provisionnement au niveau R-


seau/Transport (UC1)

Use Case 2 : Violation de politique


Nous tudions ici la rponse des composants de lAPA aprs une notifi-
cation signalant que les objectifs de politique (par exemple les objectifs de
QoS pour une application donne), qui sont supposs tre satisfaits pour
une politique oprationnelle donne, ne le sont pas. Il inclut deux acteurs :
le gestionnaire de contexte (CM), qui notifie cet vnement lAPA via le
PAM, et les agents ( un ou plusieurs niveaux) qui sont notifis par lAPA
des rgles dadaptation appliquer par les entits gres. Deux niveaux
conscutifs dadaptation sont ici considrs (Transport puis Rseau).
La Figure 2.11 fournit une vue haut niveau du diagramme de squence
impliquant les composants de lAPA et les autres composants du systme.
Lorsque le CM notifie le PAM de la violation de politique, celui-ci rcupre
auprs du rpertoire REPO la politique associe lvnement. Il rcupre
54 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

galement les paramtres de la politique oprationnelle. Une fois les po-


litiques rcupres, le PAM invoque ladaptateur de politique (lAdapter)
de niveau Transport afin de modifier la politique actuelle et prendre en
compte le changement de contexte. Si une adaptation est possible, lAdap-
ter retourne une nouvelle politique oprationnelle au PAM qui la transmet
au PEM pour quelle soit applique. La nouvelle politique est stocke dans
le rpertoire de stockage des politiques oprationnelles. Si lAdapter ne
peut pas prendre de dcision dadaptation, le PAM informe le PDM de cet
tat de fait afin que celui-ci prenne une dcision de re-provisonnement.

Figure 2.11 Diagramme de squence dune adaptation au niveau Rseau/Transport


(UC2)

2.3.2 Spcification dtaille du PDM

Le PDM est compos de trois entits cres au lancement du systme


(Figure 2.12).
La premire entit, le PDMNotificationManager, traite la notification des
2.3. Spcification dtaille des composants de lentit APA 55

Figure 2.12 Diagramme de classe du PDM

vnements auxquels il a souscrit (par exemple, "lancement dune nou-


velle application") venant du CM. Quand une notification survient, il rcu-
pre la (les) politiques correspondantes auprs du REPO et la (les) stocke
dans une base de donnes locale. Puis, il invoque la mthode processDe-
cision(Policy) du PDMWorkerManager.
Drive de la premire entit, le PDMWorkerManager prend la dci-
sion de provisionnement ncessaire un ou plusieurs niveaux (avec
laide des PolicyDecisioners adquats). Lorsquon lui demande de prendre
une dcision, le PDMWorkerManager invoque la mthode takeDeci-
sion(OpPolicy) : OpPolicy du Decisioner adquat, soit un seul niveau
ou plusieurs niveaux successivement du plus bas au plus haut. Pour
raliser cette tche, le PDMWorkerManager utilise et coordonne un ou
plusieurs PDMWorkers. Une fois la politique oprationnelle rcupre, le
PDMWorker invoque la mthode dispatch(OpPolicy) du PDMDispatcher.
Enfin, le PDMDispacher traite les interactions avec le PEM pour faire ap-
pliquer la politique et la stocker dans le rpertoire local (Op_REPO). Lors-
quil est invoqu par le PDMWorker, le PDMDispacher invoque la m-
thode enforcePolicy(OpPolicy) du PEM, puis il stocke la politique opra-
tionnelle dans le rpertoire local(Op_REPO).

2.3.3 Spcification dtaille du PAM

De faon analogue au PDM, le PAM est compos de trois entits cres au


lancement du systme (Figure 2.13) :
Le PAMNotificationManager traite la notification des vnements aux-
quels il a souscrit (par exemple, "violation dune politique") venant du
gestionnaire de contexte (CM). Quand une notification survient, il rcu-
pre la (les) politiques intermdiaires et oprationnelles correspondantes
56 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

Figure 2.13 Diagramme de classe du PAM

et la (les) stocke dans une base de donnes locale. Puis, il invoque la m-


thode processDecision(Policy) du PAMWorkerManager.
Le PAMWorkerManager prend la dcision de ladaptation ncessaire un
ou plusieurs niveaux (avec laide des PolicyAdapters adquats). Lorsquon
lui demande doprer une adaptation, le PAMWorkerManager invoque la
mthode tadaptPolicy(OpPolicy) : boolean de lAdapter adquat, soit un
seul niveau ou plusieurs niveaux successivement du plus bas au plus
haut. Comme pour le PDMWorkerManager, pour raliser cette tche, le
PAMWorkerManager utilise et coordonne un ou plusieurs PAMWorkers.
Si le rsultat de ladaptation est positif, le PAMWorkerManager invoque la
mthode dispatch(OpPolicy) du PAMDispatcher. Si ladaptation nest pas
possible, le PDM est inform par une alarme quun re-provisonnement
doit tre fait.
Enfin, le PDMDispacher traite les interactions avec le(s) PEM(s) pour faire
appliquer la politique adapte. Lorsquil est invoqu par le PAMWorker,
le PAMDispacher invoque la mthode enforce(OpPolicy) du PEM, puis il
stocke la politique oprationnelle dans le rpertoire local(Op_REPO).

2.3.4 Spcification dtaille du PEM

Le diagramme de classe du PEM est donn figure 2.14.


Le PEMEnforcementManager est un composant interne du PEM qui, en
fonction des diffrents niveaux de politique inclus dans la politique d-
ployer, dlgue la mise en uvre de la politique pour chacun de ces ni-
veaux correspondants une instance de IPolicyEnforcer.
Par exemple, une politique oprationnelle contenant des informations
mettre en uvre la fois au niveau de la couche Transport et au niveau
de la couche Rseau, utilisera une instance de IPolicyEnforcer speciali-
se dans la mise en uvre au niveau Transport (TEnforcer) et au niveau
Rseau (NEnforcer).
2.3. Spcification dtaille des composants de lentit APA 57

Figure 2.14 Diagramme de classe des composants internes PEM

La notion dAgent

Un des choix remarquables du systme NETQoS est de fournir un moyen


de grer la QoS plusieurs niveaux du systme de communication (Trans-
port, Rseau, Liaison de donnes. . .). Pourtant, lexistence de diffrents
systmes fournissant de la QoS chacune des couches considres est un
lment qui contribue sa complexit.
Afin dutiliser au mieux ces diffrentes technologies tout en maintenant
un certain niveau dabstraction dans le composant APA, les politiques de
QoS sont dcrites dans un langage propre au systme NETQoS ( NetQoS
policy). Les politiques oprationnelles qui sont issues des dcisions prises
par lAPA et qui sont achemines par le PEM vers les entits gres, sont
ainsi dcrites dans un langage indpendant de la technologie. Figure 2.15.

Figure 2.15 Problme des multiples entits gres un niveau donn


58 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

Afin de pouvoir prendre en compte une grande varit de systmes exis-


tants, le principe de ladaptateur a t appliqu. Ce concept, dnomm
Agent par la suite, est ici illustr pour le niveau Transport.
Au niveau Transport, lagent ETP (ou ETP Agent dans les diagrammes
suivants) reprsente linstance dun tel composant adaptateur au niveau
Transport.
Les principales fonctions de lETP Agent sont dune part de garder en
mmoire la liste des entits ETP existantes pour tre capable de raliser les
actions de provisionnement et dadaptation lorsquelles sont requises par
lAPA ; dautre part, lETP Agent est responsable de la transformation de la
politique oprationnelle de bas niveau en une description comprhensible
pour la technologie sous-jacente (en loccurrence ici ETP).

2.3.4.1 Cas dutilisation de lETP Agent

Les principales fonctions de lagent lETP ncessitent que des entits ETP
sexcutent sur les htes dextrmits et que lAPA soit lanc. Le PEM est
lacteur principal des scnarios dapplication. De plus, pour raliser ces
actions sur les entits ETP, lETP Agent doit les garder en mmoire. Cette
interaction implique seulement lentit ETP. Les principaux cas dutilisa-
tion de lETP Agent : EnforceDecision, ChangeParameter et Register sont
reprsents sur la Figure 2.16.

Figure 2.16 Interactions de lETP Agent avec lAPA.PEM et les entits ETP

2.3.4.2 Structure interne de lETP Agent

LETP Agent prsente des interfaces dune part avec le PEM, qui doit
contacter lETP Agent pour raliser les actions dadaptation et de dploie-
ment, et dautre part avec les entits ETP qui ralisent ces actions. Figure
2.17.
Pour chaque requte entrante en provenance du PEM, lETP Agent cre
une nouvelle instance dun objet ConnectionHandler qui sera charg de
raliser les actions requises en fonction du type de message reu. Ceci per-
2.3. Spcification dtaille des composants de lentit APA 59

Figure 2.17 Diagramme de classe de lETP agent

met une gestion multithreade des actions de dploiement afin que lchec
dune entit ETP ne retarde pas le traitement dautres requtes entrantes.
Pour une requte du PEM reue, les interactions entre les diffrents ob-
jets sont dcrits par le diagramme de structure composite de lETP Agent
(Figure 2.18).

Figure 2.18 Diagramme de structure composite de lETP Agent

Pour effectuer les actions EnforceDecision et ChangeParameter, le Connec-


tionHandler de lETP Agent utilise deux objets : un Transformer et un
Dispatcher. Le Transformer a pour rle de convertir la politique NETQoS
dcide par lAPA, exprime dans un langage indpendant de la techno-
logie, dans un langage de description dune composition ETP. De plus,
une fois que la conversion a t ralise, lobjet Dispatcher a pour rle de
contacter et de configurer les entits ETP qui ont besoin dtre adaptes.
60 Chapitre 2. Principes darchitecture dun systme de gestion auto-adaptative de la QoS

2.3.4.3 Le micro-protocole "ETP Agent Interface" dans le plan de Management

Afin de permettre une instance ETP sexcutant sur un hte dtre dy-
namiquement reconfigure par le systme NETQoS, lETP Agent commu-
nique avec un module du plan de gestion de linstance ETP.
Ce module, appel ETP Agent Interface, est implment sous la forme
dun module de traitement (processing module). Pourtant, son comporte-
ment diffre des processing modules classiques dETP. En effet, il nest pas
destin manipuler des donnes appartenant une communication. Le
rle du processing module ETP Agent Interface est de fournir un moyen
lETP Agent dinteragir avec une instance ETP en cours dexcution.
LETP Agent Interface reoit ainsi des messages venant de lETP Agent qui
sont utiliss pour reconfigurer la pile de communication active (adaptation
architecturale) et pour dynamiquement changer la valeur dune variable
partage dune instance ETP (adaptation comportementale).

Figure 2.19 Stack ETP Agent pour une adaptation distance


LETP Agent Interface est localis dans le plan de Management des ins-
tances ETP sexcutant sur les htes dextrmits. La pile ETP permettant
de dynamiquement configurer une instance ETP interagissant avec le sys-
tme NETQoS est prsent Figure 2.19.

Conclusion du chapitre

Ce chapitre a prsent nos contributions au besoin en architecture de


contrle pour la gestion adaptative de la QoS base politique, incluant
en particulier son interfaage avec le protocole de Transport configurable
ETP utilis dans nos travaux. Ces contributions, ralises dans le cadre du
projet europen NETQoS, ciblent une adaptation plus large que celle du
niveau Transport, le projet NETQoS ayant pour objectif dautomatiser la
gestion de plusieurs niveaux dadaptation potentiels (typiquement Trans-
port et Rseau), individuellement ou simultanment.
La premire partie du chapitre a prsent les acteurs du systme NETQoS,
et a prcis les besoins des acteurs "utilisateur" et "application" qui sont
viss par les solutions dadaptation de niveau Transport. La deuxime par-
tie a dcrit le modle darchitecture conceptuelle dfinie pour NETQoS et
2.3. Spcification dtaille des composants de lentit APA 61

auquel nous avons directement contribu. Les diffrentes fonctionnalits


et les composants de cette architecture permettant de dcider et de faire
appliquer des actions dadaptation au niveau Transport ont ainsi t pr-
sents au travers de plusieurs cas dutilisation. Enfin, la dernire partie
a prsent plus prcisment nos choix de conception dtaills pour les
composants nous concernant directement, lAPA et lETP Agent.
Rappelons que les objectifs du projet NETQoS taient de contribuer au d-
veloppement dun modle darchitecture conceptuelle, indpendante dun
environnement rseau spcifique. Cet objectif de gnricit vis--vis de
lenvironnement rseau, qui nous a conduit ladoption dune dmarche
de conception top-down, nous a ainsi amens proposer des modles
tant au niveau de larchitecture gnrale du systme que des composants
nous concernant directement, qui seraient certainement revus dans une
approche guide par les caractristiques dun environnement rseau sp-
cifique. Bien que nous nayons pas suivi cette approche, les principes de
conception du systme NETQoS nous semblent cependant susceptibles
dtre directement applicables dans la dfinition dun modle adapt un
contexte de rseau ferm dont les nuds seraient en nombre limit. Cette
intuition, intressante pour le contexte des oprations dintervention dur-
gence (OIU), na cependant pas t explore dans nos travaux.
En effet, la perspective que nous avons choisie concerne le dveloppement
de modles et dalgorithmes pour le choix des dcisions dadaptation, et
llaboration des actions dadaptation impactes par ces modles. Cette
perspective, trs peu explore dans le cadre du projet NETQoS, est en
effet ncessaire la mise en uvre dun systme tel que NETQoS, qui
en ltat des travaux prsents dans ce chapitre ne dfinit que le cadre
architectural pour guider les dcisions et leur application.
Le chapitre 3 ci-aprs prsente nos contributions, ralises hors du projet
NETQoS, dans cette perspective.
Gestion cooprative de la
QoS au niveau Transport 3

Sommaire
3.1 Rpartition de la bande passante . . . . . . . . . . . . . . . 67
3.1.1 Contexte applicatif et exemple : les OIU . . . . . . . . . . . 67
3.1.2 Description des Oprations dIntervention dUrgence (OIU) 68
3.1.3 Problmatique et approche . . . . . . . . . . . . . . . . . . 70
3.1.4 Formalisation du problme . . . . . . . . . . . . . . . . . . 73
3.1.5 Calcul de la rpartition de bande passante . . . . . . . . . 74
3.1.6 Problme P1 : minimiser la bande passante globale cde . 75
3.1.7 Ajout dun deuxime critre et dfinition du problme P2 :
minimiser lexcdent de bande passante libre . . . . . . 80
3.1.8 Conclusion sur lutilisation des critres de minimisation
globale (z1 ) et de minimisation des excdents (z2 ) . . . . . 82
3.2 Gestion cooprative de la QoS dans le systme NETQoS 82
3.2.1 Identification des connexions . . . . . . . . . . . . . . . . . 82
3.2.2 Classe MoMe . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.2.3 Mise en uvre du processus de coopration . . . . . . . . 84
3.2.4 Diagramme de squence pour la coopration . . . . . . . . 84
3.3 Outils et protocoles pour la rcupration des infor-
mations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
SNMP . . . . . . . . . . . . . . . .
3.3.1 . . . . . . . . . . . . . . 86
Traceroute . . . . . . . . . . . . . .
3.3.2 . . . . . . . . . . . . . . 87
Protocoles de routage . . . . . . .
3.3.3 . . . . . . . . . . . . . . 88
Fonctions de Monitoring dans ETP
3.3.4 . . . . . . . . . . . . . . 88
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

D ans le chapitre prcdent, nous avons prsent nos contributions en


termes darchitecture pour la gestion autonome de la QoS plusieurs
niveaux, en particulier au niveau Transport.
Dans ce chapitre, nous proposons une approche de gestion cooprative de
la QoS au niveau Transport. Les mcanismes classiques de gestion de la
QoS (contrle derreur, contrle de congestion) ou les mcanismes de ges-
tion de la QoS orients multimdias (contrle derreur avec fiabilit par-
tielle, contrle de congestion tenant compte des contraintes de temps,. . .)

63
64 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

oprent connexion par connexion et visent une rpartition quitable de


la QoS entre les diffrentes connexions. Cependant, il est envisageable
dans certains environnements applicatifs de remettre en cause ce principe
dquit et de considrer une gestion cooprative de la QoS par groupe
de connexions. Ceci est le cas notamment pour des applications o les
relations entre les utilisateurs sont hirarchises. Dans de telles applica-
tions, on peut envisager, lorsque les ressources manquent, de maintenir
la QoS des connexions des utilisateurs les plus prioritaires au dtriment
des connexions dutilisateurs moins prioritaires. La gestion coordonne
de connexion a dej fait lobjet de travaux que nous avons prsents en
section 1.4.6 du chapitre 1. Notre approche de gestion cooprative de la
QoS au niveau Transport sinspire notamment de la gestion de la QoS
dans les protocoles de Transport multi-connexions [CHA 96], [OWE 98],
[STE 04].
Pour mettre en uvre une telle gestion de la QoS, plusieurs aspects sont
considrer :
la rpartition des ressources. Connaissant la QoS requise par les
connexions impliques dans la collaboration et la quantit de ressources
disponibles dans le rseau, le besoin est de calculer une rpartition dif-
frente de ces ressources au profit des connexions les plus prioritaires.
la rcupration des donnes de supervision. Pour pouvoir calculer la rparti-
tion voque ci-dessus, il est ncessaire de collecter les informations de
QoS relatives aux diffrentes connexions. La collecte de ces informations
ncessite des changes de messages et donc la mise en uvre dun pro-
tocole appropri. Ce protocole dpend de la manire dont est envisage
la mise en uvre du calcul de la rpartition des ressources. Ce calcul
peut tre centralis, distribu, sur les htes dextrmits, au niveau des
routeurs, etc,. . .
la mise en uvre au niveau des htes dextrmit. Le dploiement de la
dcision de rpartition des ressources implique galement la mise en
uvre dun protocole de (re-)configuration pour les entits de niveau
Transport. Lui aussi dpendra de la faon dont sont mis en uvre le
calcul de la rpartition des ressources et la collecte des donnes de
supervision.

La faon dimplanter les diffrents composants permettant de rpondre


aux trois besoins dcrits ci-dessus, constitue larchitecture du systme de
gestion cooprative de la QoS.
Dans ce chapitre, nous nous intressons dans une premire partie (sec-
tion 3.1) au problme de la rpartition de la bande passante entre les
connexions en tenant compte de leurs diffrentes priorits. Aprs avoir ex-
plicit le problme et dfini les donnes ncessaires sa rsolution, nous
le formulons sous la forme dun problme doptimisation. Deux critres
de minimisation sont introduits et discuts.
Dans une deuxime partie, nous prsentons les extensions de larchitec-
ture du systme NETQoS, prsent au chapitre prcdent, ncessaires
pour effectuer une gestion cooprative de la QoS. Les extensions propo-
ses concernent toujours larchitecture fonctionnelle.
65

Enfin, une troisime partie (section 3.3) propose des lments de rflexion,
en termes de protocoles et doutils pour la collecte des donnes de super-
vision.
3.1. Rpartition de la bande passante 67

3.1 Rpartition de la bande passante

Nous considrons des activits coopratives distribues qui sappuient


sur des groupes structurs dutilisateurs induisant des priorits entre les
communications qui se rpercutent sur les connexions de Transport sous-
tendant le transfert des donnes correspondantes.
Lvolution des activits coopratives distribues peut intervenir des mo-
ments prvisibles ou non. Cette volution peut rsulter dun changement
dans la composition du groupe ou dans la rpartition des rles sur les
membres du groupe. Cette volution induit galement un changement
dans les priorits de communication. Une nouvelle rpartition des res-
sources de communication est alors calculer. Dun autre cot, et notam-
ment pour les activits soutenues par des moyens de communications sans
fil, la redistribution des ressources peut savrer ncessaire pour adapter
les protocoles de communication aux variations des contraintes de linfra-
structure de communication. Par exemple, le contexte des rseaux sans fil,
mobiles et ad-hoc implique une variation des ressources, notamment de
la bande passante. On envisage alors de rpartir la bande passante de ma-
nire diffrente entre les connexions de Transport en fonction des priorits
des utilisateurs et des communications associes.
Cette section explicite titre dexemple le contexte des applications co-
opratives distribues sur des rseaux mobiles, notamment celui des OIU,
puis prsente le problme de la rpartition de la bande passante dans un
contexte de rseau filaire pour une adaptation aux changements dans le
contexte applicatif. Le modle doptimisation permettant la rsolution de
ce problme est ensuite prsent et discut.

3.1.1 Contexte applicatif et exemple : les OIU

Les rseaux sans fil et ad-hoc, les rseaux de capteurs et les quipements
mobiles de type PDA ou smartphone, sont les technologies qui sous-
tendront le dploiement de nouveaux services dans les futurs rseaux
ambiants, ubiquitaires et pervasifs.
Les technologies des rseaux ambiants prsentent des caractristiques dif-
frentes de celles sur lesquelles sappuient les services actuels de lInter-
net, cest--dire des rseaux filaires haut dbit, des quipements fixes
fortes ressources en termes de capacit de calcul, de stockage, et dner-
gie. Comparativement, dans les rseaux ambiants, la bande passante est
variable car fonction de la localisation et de la mobilit des utilisateurs, de
leur point daccs courant et des perturbations courantes des liens sans fil.
En outre, les ressources des quipements sont potentiellement limites.
Par ailleurs, ce type denvironnement ouvre des perspectives applicatives
nouvelles autorisant la coopration dynamique dutilisateurs mobiles dans
le cadre dexercices tels que les OIU en situation de crise. Les OIU im-
pliquent des groupes structurs dindividus collaborant une mission
commune ; par essence, ces oprations ne peuvent pas sappuyer sur une
infrastructure de rseaux uniquement filaires, en raison de la mobilit de
68 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

certains des intervenants et de labsence totale ou partielle de linfrastruc-


ture de communication initiale. Les communications sappuient donc sur
des rseaux sans fil, potentiellement ad-hoc, et sur des machines aux capa-
cits potentiellement limites, dont les ressources sont par nature variables
et le plus souvent limites.
Pour aider au dploiement de ce type dactivit, les futurs services de
communication, quils relvent des couches application, transport ou r-
seau auront prendre en compte des besoins multiples et volutifs dans le
temps lis lactivit cible, la mobilit des utilisateurs, aux flux de don-
nes changs (audio, vido,. . .) et aux contraintes de lenvironnement de
communication. De plus, pour des activits telles que les OIU, lvolution
de la mission induira invitablement des changements dans la hirarchie
et dans la structure des cooprations entre intervenants, par exemple suite
aux informations acquises par les excutants sur le terrain ou par les d-
cisions des coordinateurs de la mission.
Les paragraphes suivants dcrivent un scnario dactivit cooprative de
type OIU. Au travers de ce scnario simple, nous illustrons en quoi ce
type dactivit induit une variation des priorits des communications en
fonction de lvolution de la mission.

3.1.2 Description des Oprations dIntervention dUrgence (OIU)

Pour des activits de type OIU, la coopration est base sur lchange
dinformations entre des participants mobiles, collaborant la ralisation
dune mission commune. Ces informations peuvent tre des donnes de
diffrents types, notamment des donnes dobservation et des donnes
danalyse, produites priodiquement ou immdiatement aprs un vne-
ment particulier.
Ces donnes sont transmises sous diffrentes formes (mdia), notamment
textuelle, audio et/ou vido. Chaque mdia possde diffrents codecs tels
que H263 ou MPEG4, qui induisent des besoins en QoS diffrents pour
le transfert des donnes de bout-en-bout. Les besoins en QoS peuvent
tre exprims en termes de bande passante, de pourcentage de pertes, de
contraintes de synchronisation intra/inter-media. Ils peuvent aussi tre
exprims sous forme de contraintes temporelles dues linteractivit re-
quise entre les participants.
Les participants possdent des terminaux mobiles, et communiquent via
des rseaux filaires ou sans fil. En fonction du rle quil occupe dans la
mission, chaque participant fournit un ensemble de services. Les services
que les participants doivent fournir sont dynamiquement assigns aux
participants selon lvolution de la mission, en fonction de leurs capacits
et leur localisation.
Une quipe dintervention durgence peut ainsi tre constitue de partici-
pants ayant diffrents rles, par exemple : un contrleur de la mission, plu-
sieurs coordinateurs, et plusieurs quipes dinvestigateurs, chacun dirig
par un coordinateur. Chaque participant peut remplir diffrentes fonc-
tions :
3.1. Rpartition de la bande passante 69

le contrleur a par exemple pour fonction de diriger et dautoriser les


actions qui doivent tre ralises par les coordinateurs et les investiga-
teurs ;
en relation avec le contrleur et les autres coordinateurs, un coordina-
teur doit diriger ses investigateurs, en leur prcisant les tches rali-
ser. Il doit galement collecter, interprter, synthtiser les informations
reues des investigateurs et les diffuser vers les investigateurs ;
les investigateurs ont pour fonction dexplorer le champ oprationnel,
dobserver, danalyser, et de faire un rapport dcrivant la situation. Les
investigateurs peuvent galement aider, porter secours, rparer, etc.

On considre le scnario dune quipe dintervention durgence compose


dun contrleur fixe, appel C, et de deux investigateurs, A et B, se dpla-
ant sur un champ dexploration. Pour simplifier lexplication du modle,
le contrleur remplit les rles du contrleur et du coordinateur.
Les fonctions remplies par les investigateurs sont dObserver (O) le champ
dexploration et de Rapporter (R) sur ce qui est observ. Dans les deux
cas, des donnes de retour (feedback) sont envoyes au contrleur. Les
feedback D (associs la fonction O) sont des donnes Descriptives ; elles
sont transmises sous forme audio/vido (a,v). Les feedback P (associs
la fonction R) sont des donnes Produites ; elles expriment lanalyse de la
situation par un investigateur. Elles sont transmises sous forme audio (a).
La fonction du contrleur est de Superviser lensemble de la mission, en
dcidant des actions excuter en fonction de lobservation et de lana-
lyse des feedback D transmis par les investigateurs. Pour prendre cette
dcision, le contrleur peut galement utiliser les feedback P transmis par
les investigateurs. Enfin, chaque participant est suppos possder un seul
terminal mobile, quip dune technologie sans fil pour la communication.

Figure 3.1 Scnario dOpration dIntervention dUrgence

Le scenario est divis en deux tapes successives (Figure 3.1).


70 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

La premire tape est ltape dinvestigation. Les investigateurs A et


B envoient de manire continue des feedback D au contrleur C ; ils
envoient galement des feedback P priodiquement. Il ny a pas de dif-
frence de priorit entre les communications A-C et B-C, mais la trans-
mission des feedback D est plus importante que celle des feedback P. La
premire tape se termine quand une situation critique est dcouverte
par un investigateur, par exemple A.
La deuxime tape est ltape daction. Aprs avoir dcouvert une si-
tuation critique, A continue de remplir les mmes fonctions que durant
ltape dexploration (Observer et Rapporter), mais envoie aussi les
feedback D linvestigateur B. Il continue denvoyer des feedback P
C ; B rapporte maintenant seulement des feedback P au contrleur C ;
elles correspondent lanalyse des feedback D transmis par A.

En raison du caractre critique de la situation dcrite par A, la commu-


nication A-C est plus importante que les communications A-B et A-C. De
plus, les changes de feedback D entre A et C sont les plus importants ; les
donnes P entre A et C sont dimportance moyenne ; les feedback D entre
A et B, et les feedback P entre B et C sont les moins prioritaires.
Ce scnario fait donc apparaitre des priorits entres les communications.
Ces priorits sont amenes voluer au cours de la mission. Au niveau
des connexions de Transport sous-jacentes, on souhaite rpartir la bande
passante dont bnficie chacune de ces connexions en fonction de leurs
priorits relatives. Cette problmatique et la faon dont nous proposons
de laborder sont dcrites dans la section suivante.

3.1.3 Problmatique et approche

La problmatique lie au contexte prcdent est la suivante. Les appli-


cations multimdias prsentent des besoins en QoS et lenvironnement
considr implique potentiellement une pnurie de ressources, notam-
ment une bande passante limite et variable. De plus il existe des priorits
entre les communications, lies au caractre collaboratif des applications
ainsi qu la structure hirarchique du groupe dutilisateurs considr.
Notre approche consiste tirer partie de ces priorits dans la gestion de la
QoS au niveau Transport, en maintenant la QoS associe une connexion
au dtriment de la QoS dune ou plusieurs autres connexions, moins prio-
ritaires. Nous nous appuyons pour cela sur les protocoles de Transport
configurables.
Pour aborder cette problmatique, nous avons dcid dtudier la mise
en uvre de lapproche consistant amliorer le dbit obtenu par une
connexion en dgradant celui dune ou plusieurs autres connexions dans
un contexte filaire dans un premier temps, afin den valuer la pertinence
et la difficult de mise en uvre. La considration dautres paramtres de
QoS est une perspective de nos travaux, de mme que la considration
dun contexte de rseaux sans fil.
Lapproche classique, non cooprative, consistant grer la pnurie de
ressources de manire quitable amne une dgradation de toutes les
3.1. Rpartition de la bande passante 71

connexions y compris des plus importantes. On cherche donc, comme


par exemple avec le PHB des rseaux DiffServ qui traite de faon prio-
ritaire les paquets les plus importants, donner plus de bande passante
aux connexions les plus prioritaires. Cette approche cooprative est dcrite
dans les sections suivantes.

Description informelle de lapproche propose

On considre une topologie de rseau constitue de N nuds et dun


nombre C de connexions. A chaque connexion sont associs des besoins en
QoS que nous limitons ici au dbit requis. Le dbit dmission de chaque
connexion dcoule de la mise en uvre dun mcanisme de contrle de
congestion, qui de manire classique vite leffondrement du rseau. Pour
mettre en place notre approche de gestion cooprative de la QoS, nous fai-
sons lhypothse que les dbits dmission sont des dbits moyens qui res-
tent stables sur une priode de temps significativement longue, de lordre
de la centaine de secondes, ventuellement mme de quelques minutes.
Lhypothse dune telle priode de stabilit du rseau, est ncessaire pour
pouvoir envisager de faire collaborer les connexions en dgradant la QoS
de certaines au profit dautres.
Le paramtre de QoS que nous souhaitons amliorer est le dbit dmis-
sion obtenu par une application. Si une connexion nobtient pas une bande
passante satisfaisante au regard de ses besoins en QoS, cest- dire que son
dbit dmission est infrieur au dbit requis par lapplication, on cherche
alors augmenter ce dbit dmission de la quantit manquante. Nous
appelons cette quantit manquante lincrment. Pour pouvoir augmenter
le dbit de cette connexion et maintenir un niveau de congestion accep-
table, il faut trouver quelles connexions doivent diminuer leur dbit afin
de librer la bande passante ncessaire. La quantit de bande passante
libre par ces connexions est appele le dcrment.
La rcupration des diffrentes informations relatives la mise en uvre
de cette approche, la possibilit de trouver une solution et le dploiement
de la solution, cest--dire sa mise en application sur les htes dextrmit
reposent sur lhypothse de stabilit des dbits moyens des applications
dans le rseau pendant une priode de temps suffisamment longue.

Priorits des connexions

On considre dans un premier temps deux types de connexions, aux prio-


rits diffrentes :
les connexions de type 0 (les moins prioritaires) qui ne pourront jamais
bnficier dune augmentation de bande passante, mais qui seront en
revanche amenes collaborer, cest--dire donner une partie de leur
bande passante des connexions de type 1 (plus prioritaires) dfinies
ci-dessous. Dans la suite de ce chapitre, nous appelons les connexions
de type 0 connexions donneuses ; tel quindiqu ci-dessus, la quantit de
bande passante que chacune donne est appel le dcrment.
les connexions de type 1 (les plus prioritaires) qui ne cderont jamais
72 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

une partie de leur bande passante, mais qui seront amenes deman-
der aux connexions de type 0 de collaborer en donnant une partie de
leur bande passante lorsque la valeur de la bande passante dont elles
disposent passe en-de dun certain seuil. Dans la suite de ce chapitre,
nous appelons ces connexions connexions receveuses ; tel quindiqu ci-
dessus, la quantit de bande passante que rclame chacune est appel
lincrment.

Nous ne considrons ici que deux types de connexions afin de simplifier la


complexit du problme. En effet, considrer simplement des connexions
qui cdent de la bande passante et des connexions qui reoivent de
la bande passante, permet dviter de traiter dventuels conflits. Par
exemple, si une connexion peut la fois donner et recevoir, il peut se trou-
ver une situation dans laquelle la connexion donne et ce faisant obtient un
dbit dmission insuffisant qui implique une coopration induisant une
augmentation de dbit. On peut sattendre alors un phnomne dos-
cillations. Le but de notre tude tant de montrer la pertinence dun m-
canisme permettant daugmenter le dbit dune connexion au dtriment
dune ou plusieurs autres, nous vitons de traiter le type de problmes lis
la gestion de priorits multiples en ne considrant que des connexions
exclusivement donneuses ou receveuses.
Dans un deuxime temps, en perspective de ce travail, on peut envisager
une gestion plus complexe des connexions qui pourraient endosser les
deux rles, donneuses et receveuses, la fois. Il faudrait alors rsoudre les
conflits qui en rsultent. De plus on peut envisager des priorits entre les
connexions donneuses et/ou entre les connexions receveuses.

Routeurs, interfaces et ressources disponibles

On considre dans cette tude des liens full-duplex entre les routeurs
et une capacit des interfaces en sortie des routeurs gale la capacit
des interfaces en entre des routeurs. Dans les exemples qui suivent, les
liens considrs autorisent des connexions dans un seul sens, donc les
connexions qui sortent dune interface se partagent la bande passante
correspondant la capacit de cette interface. Par consquent, pour une
connexion, le goulot dtranglement qui fixe son dbit dmission est
constitu par linterface de sortie dun des routeurs de son chemin de don-
nes. Dans la suite, on parlera donc dinterface sans prciser quil sagit
dune interface de sortie.
Une connexion receveuse rclame un incrment de dbit lorsquune ou
plusieurs interfaces sur son chemin de donnes ne possdent pas les res-
sources suffisantes pour lui permettre dobtenir le dbit quelle souhaite.
Dans la suite de notre tude nous distinguons deux types dinterfaces : les
interfaces non charges et les interfaces charges.

Dfinition 3.1 Une interface non charge est une interface pour laquelle la somme des dbits des
connexions sortantes est infrieure la capacit en sortie de cette interface.

Exemple : Si on considre trois flux mettant un dbit moyen de


3.1. Rpartition de la bande passante 73

2Mbits/s et passant par un routeur dont linterface de sortie offre un dbit


de 10Mbits/s, on voit alors clairement que linterface nest pas charge et
quelle possde mme une "marge".

Dfinition 3.2 La marge dune interface est dfinie par la diffrence entre la somme des dbits
sortants et la capacit en sortie de linterface.

Dans notre exemple, la marge est gale 10 - (3 x 2) = 4 Mbits/s.

Dfinition 3.3 Une interface est charge lorsque la somme des dbits sortants et la somme des
incrments requis est suprieure la capacit du lien en sortie de linterface.

Dfinition 3.4 Un routeur est charg lorsque lune au moins de ses interfaces est charge. On
note Rch , lensemble des routeurs chargs.

3.1.4 Formalisation du problme

Dans cette section, nous formalisons les diffrentes notions dcrites dans
la section prcdente prsentant le problme de rpartion de la bande
passante.

Dfinition 3.5 On appelle R lensemble des routeurs ri du rseau, R = {ri }. Un routeur ri est
dfini par un ensemble dinterfaces I j .

Dfinition 3.6 On appelle "donneuse" une connexion qui peut donner une partie de sa bande
passante au profit dautres connexions plus prioritaires qui partagent avec elle
des ressources communes (les routeurs et leurs interfaces). On note D, lensemble
des connexions de ce type prsentes dans le rseau considr.
tobt
D = {di } avec di =
R t = {r j } R tel que r j est un routeur par lequel passe di
avec di .tobt , la valeur du dbit moyen obtenu par la connexion di , di . le dcrment
de di et di .Rt , lensemble des routeurs du chemin de donnes de di .

Dfinition 3.7 On appelle "receveuse" une connexion qui rclame un incrment de dbit. On
note P, lensemble des connexions de ce type prsentes dans le rseau considr.
treq
t
P = { pi } avec pi = obt

R t = {r j } R tel que r j est un routeur par lequel passe pi
avec pi .treq , la valeur du dbit moyen requis par la connexion pi , pi .tobt , la va-
leur du dbit moyen obtenu par pi , pi . lincrment de dbit souhait et pi .Rt ,
lensemble des routeurs du chemin de donnes de pi .

Dfinition 3.8 La quantit pi . de bande passante obtenir pour une application lie une
connexion receveuse est donne par :

pi . = pi .treq pi .tobt
74 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

Dfinition 3.9 Une interface Ii est dfinie par :

{ De , Ds }
{ Pe , Ps }
Ii =
c

Avec :
Ii .De , le sous-ensemble des connexions donneuses entrant sur cette interface et
Ii .Ds , le sous-ensemble des connexions donneuses sortant de cette interface ;
Ii .Pe , le sous-ensemble des connexions receveuses entrant sur cette interface et
Ii .Ps , le sous-ensemble des connexions receveuses sortant de cette interface ;
Ii .c, la capacit du lien en sortie de cette interface ;
Ii . la marge associe cette interface (cf. la dfinition 3.2).

Dfinition 3.10 La marge dune interface I j est donne par :


!
I j . = I j .c I j .di .tobt + I j .pk .tobt
di I j .Ds pk I j .Ps

Dfinition 3.11 Une interface Ii est charge lorsque la somme des dbits sortants des connexions
donneuses et receveuses sur cette interface, plus la somme des incrments des
connexions receveuses est suprieure la capacit en sortie de cette interface.

d j .tobt + ( p j .tobt + p j .) > Ii .c


d j Ii .Ds p j Ii .Ps

Remarque 3.1 Dans lexpression ci-dessus, la somme des dbits obtenus par les connexions don-
neuses et receveuses :

d j .tobt + p j .tobt
d j Ii .Ds p j Ii .Ps

ne pouvant pas excder I j .c, alors si linterface est charge, cest quil existe au
moins un terme p j . non nul. En dautres termes, une interface charge est forc-
ment traverse par au moins une connexion receveuse.

Exemple : Considrons trois flux qui mettent un dbit moyen de 2


Mbits/s, souhaitant chacun une augmentation de dbit de 0.5 Mbits/s
et passant par un routeur dont linterface de sortie offre un dbit de 7
Mbits/s, on obtient :
(3 2) + (3 0.5) = 7.5 Mbits/s, ce qui est suprieur la capacit en
sortie de linterface (7 Mbits/s). Linterface est donc charge.

3.1.5 Calcul de la rpartition de bande passante

Considrons une connexion p j de type 1 (receveuse) qui voit le dbit dont


elle dispose atteindre une valeur infrieure au seuil acceptable de QoS.
Pour augmenter le dbit de cette connexion et procder une nouvelle
rpartition de la bande passante au niveau des autres connexions, il faut :
3.1. Rpartition de la bande passante 75

1) Identifier la valeur de p j ., telle que dfinie par la dfinition 3.8.


2) Identifier les routeurs, dont au moins une interface est charge, du che-
min de donnes de cette connexion (routeurs de lensemble Rch ).
Les interfaces charges des routeurs vont permettre de dfinir lensemble
des connexions qui peuvent collaborer (parmi celles qui traversent ces rou-
teurs) en donnant tout ou partie de leur bande passante, tandis que pour
les interfaces non charges des routeurs, on ne tiendra pas compte des
connexions qui les traversent. En effet, on considre quun routeur dont
linterface est non charge, peut supporter laugmentation de dbit re-
quise, sans quil soit ncessaire de rduire le dbit de la mme quantit
pour les autres connexions qui traversent cette interface non charge.
On note D lensemble des connexions donneuses passant par les routeurs
de lensemble Rch (D D) .
En se basant sur les dfinitions prcdentes, nous cherchons calculer
les dcrments des connexions donneuses di D en fonction des incr-
ments requis par les connexions receveuses. Les dcrments nots di .
correspondent la diminution de dbit que vont subir les connexions don-
neuses. On cherche donc les minimiser en fonction du besoin sur chaque
routeur. La section suivante prsente une formalisation de ce problme.

3.1.6 Problme P1 : minimiser la bande passante globale cde

Le problme considr, qui consiste dterminer les dcrments ap-


pliquer aux connexions donneuses afin de satisfaire les besoins des
connexions receveuses ne bnficiant pas dune bande passante suffisante,
admet un ensemble de solutions, parmi lesquelles nous allons choisir
celles qui optimisent un certain critre z1 . Le critre considr concerne
la quantit de bande passante libre dans sa globalit quil va sagir de
minimiser. Nous posons donc le problme suivant :

Minimiser z1 = di .
di D

avec les contraintes, rk Rch , Il charge :

di . p j . Il .

(1)
di Il .Ds p j Il .Ps


et
di . di .tobt i = 1, . . . , card(D) (2)



di . 0 (3)

La contrainte (1) exprime que pour tout routeur possdant une interface
charge, et pour toute interface charge de ce routeur, la quantit de bande
passante librer par les connexions donneuses doit au moins tre gale
la quantit totale de bande passante requise par les connexions receveuses
moins la marge restante sur cette interface.
La contrainte (2) exprime que la quantit de bande passante cde par une
connexion doit tre infrieure au dbit courant de cette connexion.
76 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

La contrainte (3) exprime que les quantits recherches sont ncssaire-


ment positives.
La section suivante prsente deux exemples illustratifs du problme ainsi
dfini et de sa solution. Le deuxime exemple permet en particulier din-
troduire un second problme que nous dfinissons en suivant.

3.1.6.1 Exemple 1

d3
p1

d2

r2
r1

d1

Connexion receveuse
Connexion donneuse
Figure 3.2 Rseau de connexions

Soit le rseau simple illustr figure 3.2 faisant apparatre quatre


connexions dont une receveuse et trois donneuses, et deux routeurs.
Les notations prcdentes appliques au rseau de la figure 3.2 donnent :
R = {r1 , r2 } = ensemble de routeurs impliqus dans le chemin de la connexion receveuse ;
P = { p1 } = ensemble des connexions receveuses, ici rduite une seule ;
D = {d1 , d2 , d3 } = ensemble des connexions donneuses.

treq = 17
tobt = 6
tobt = 7
p1 = d1 =
= 10
R t = {r1 , r2 }
R t = {r1 , r2 }
tobt = 5 tobt = 7
d2 = d3 =
R t = {r1 , r2 } R t = {r2 }
Deux interfaces nous intressent : celles que traverse en sortie la connexion
p1 sur le routeur r1 et sur le routeur r2 :

Ds = { d 1 , d 2 } Ds = { d 2 , d 3 }
P = { p1 } P = { p1 }
r1 .I1 = s r2 .I1 = s
c = 18 c = 19
=0 =0
Dans cet exemple, les capacits associes aux deux interfaces considrer,
les dbits des connexions qui les traversent et lincrment requis par la
connexion p1 font que, daprs la definition 3.11, ces interfaces sont char-
ges et daprs la dfinition 3.10, leurs marges sont nulles.
3.1. Rpartition de la bande passante 77

Le problme P1 consiste dterminer les quantits d1 ., d2 . et d3 ., d-


crments des connexions donneuses d1 , d2 et d3 compensant lincrment
p1 . = 10 de la connexion receveuse p1 et qui minimisent le critre z1 , la
quantit de bande passante globale libre.
Le problme P1 sexprime alors ainsi :

Minimiser z1 = d1 . + d2 . + d3 .
d1 . + d2 . p1 .






d2 . + d3 . p1 .




d1 . d1 .tobt

avec les contraintes
d . d2 .tobt
2




d3 . d2 .tobt




d1 ., d2 ., d3 . 0

Aprs instanciation, on obtient :

Minimiser z1 = d1 . + d2 . + d3 .
d1 . + d2 . 10






d2 . + d3 . 10




d1 . 6

avec les contraintes
d . 5
2




d3 . 7




d1 ., d2 ., d3 . 0

Le problme P1 est pos sous la forme dun ensemble dingalits linaires


sur n variables relles et dune fonction objectif, qui est elle aussi linaire.
Lalgorithme du simplexe [DAN 55] permet de trouver une solution opti-
male pour la fonction objectif.
Pour notre exemple, on obtient alors une solution optimale donne par :
d1 . = 5, d2 . = 5, d3 . = 5.

Remarque 3.2 Lalgorithme du simplexe est une technique fondamentale pour les problmes de
programmation linaire. Il est trs efficace en pratique et il est implment dans la
plupart des solveurs de programmes linaires.
En termes gomtriques, lensemble des ingalits linaires dfinit un polytope
dans lespace n dimensions et il sagit de trouver un sommet optimal pour la
fonction de cot donne. Lide de lalgorithme consiste partir dun sommet
quelconque du polytope et, chaque itration, daller un sommet adjacent sil
est possible den trouver un meilleur pour la fonction objectif. Sil ny en a pas,
lalgorithme sarrte en concluant que le sommet courant est optimal.
On peut donc remarquer que sil y a plusieurs sommets optimaux, on peut les
trouver en rexcutant lalgorithme en partant dun sommet diffrent chaque
fois. Nous utilisons pour notre problme un algorithme du simplexe ainsi modifi
qui permet, laide de permutations exhaustives, de trouver plusieurs sommets
solutions pour la fonction objectif.
78 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

Dfinition 3.12 On appelle Simplexe avec permutations, lalgorithme du simplexe modifi


permettant de trouver plusieurs sommets solutions pour la fonction objectif.

3.1.6.2 Exemple 2

Dans ce second exemple, nous considrons un rseau plus complexe qui


fait apparatre plusieurs connexions receveuses.

p1
d3

d2

d1 r1 r4
p2
r2

Connexion receveuse
Connexion donneuse
r3
Routeur non charg

Figure 3.3 Rseau de connexions

Les notations prcdentes appliques au rseau de la figure 3.3 donnent :


R = {r1 , r2 , r3 , r4 }
P = { p1 , p2 }
D = { d1 , d2 , d3 }

tobt = 10 tobt = 10 tobt = 10


p1 = =5 p2 = =5 d1 =
R t = {r1 , r2 , r4 } R t = {r1 , r2 , r3 } R t = {r1 , r2 , r3 }

tobt = 10 tobt = 10
d2 = d3 =
R t = {r1 , r2 , r4 } R t = {r2 , r3 }
Remarquons quau moins lun des routeurs chargs a une marge nulle,
puisquil existe forcment une interface du chemin de donnes qui consti-
tue un goulot dtranglement, fixant les dbits des connexions.
La capacit des interfaces des diffrents routeurs et la marge restante sur
ces interfaces (definition 3.2) sont les suivantes :
Ds = { d 1 , d 2 } Ds = { d 2 , d 3 }
Ps = { p1 , p2 } P = { p1 }
r1 .I1 = r2 .I1 = s
c = 40 c = 34
=0 =4
3.1. Rpartition de la bande passante 79

Ds = { d 1 } Ds = { d 1 }
Ps = { p2 } P = { p2 }
r2 .I2 = r3 .I1 = s
c = 22 c = 23
=2 =3
Dans cet exemple, les capacits associes aux quatre interfaces consid-
res, les dbits des connexions qui les traversent et lincrment requis par
les connexions p1 et p2 font que, daprs la dfinition 3.11, ces interfaces
sont charges.
Ds = { d 2 , d 3 }
P = { p1 }
En revanche, linterface r4 .I1 = s est, daprs la dfinition
c = 40
= 10
3.11, une interface non charge. Les connexions donneuses qui la tra-
versent, ne seront donc pas considres pour le calcul des dcrments,
puisque cette interface peut supporter lincrment demand par p1 sans
devenir charge.
Le problme P1 consiste dterminer les quantits d1 ., d2 . et d3 ., d-
crments des connexions donneuses d1 , d2 et d3 compensant les incrments
p1 . = 5 et p2 . = 5 des connexions receveuses p1 et p2 , et qui minimise le
critre z1 , la quantit de bande passante globale libre.
P1 sexprime alors ainsi :

Minimiser z1 = d1 . + d2 . + d3 .

d1 . + d2 . p1 . + p2 . r1 .I1 .


2 . + d3 . p1 . r2 .I1 .




d
d . p . r .I .


1 2 2 2



d 1 . p 2 . r 3 .I1 .

avec les contraintes

d1 . d1 .tobt
d2 . d2 .tobt




d3 . d2 .tobt







d1 ., d2 ., d3 . 0

Par suite, on obtient :

Minimiser z1 = d1 . + d2 . + d3 .
d1 . + d2 . 10


d2 . + d3 . 1





d1 . 3






avec les contraintes d1 . 10
d2 . 10




d3 . 10







d1 ., d2 ., d3 . 0

80 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

En utilisant lalgorithme du simplexe avec permutations (dfinition 3.12),


on obtient deux sommets solution :
d1 . = 9, d2 . = 1, d3 . = 0
et
d1 . = 3, d2 . = 7, d3 . = 0

3.1.7 Ajout dun deuxime critre et dfinition du problme P2 : mini-


miser lexcdent de bande passante libre

Lexemple prcdent met en vidence le fait que le critre utilis par le


problme P1 , cest--dire z1 , peut aboutir plusieurs solutions. Dans cette
section, nous nous proposons de discriminer ces solutions au regard dun
critre supplmentaire (z2 ) visant minimiser la somme des quantits
dexcdent de bande passante libre au niveau de chaque interface.
En effet, le dbit des connexions tant obtenu de bout-en-bout, il peut ar-
river que la quantit de bande passante libre sur une interface soit plus
importante que ncessaire, en fonction de la topologie des connexions. Il
peut alors tre intressant de chercher minimiser cette quantit exc-
dentaire de bande passante libre. De manire informelle, lexcdent de
bande passante libre au niveau dune interface correspond la marge
de cette interface, ajoute la quantit de bande passante cde par les
connexions donneuses sortant par cette interface, auquelles on soustrait la
quantit requise par les connexions receveuses sortant par cette interface.
Lexcdent au niveau dune interface Il , not Il ., est donn par :

Il . = di . + Il . di .
di Il di Il

Les marges et les incrments sont des constantes qui peuvent donc tre
ignores dans le critre. Si on cherche minimiser globalement lexcdent
sur les interfaces charges, le critre sexprime donc comme suit :

Minimiser z2 = k i di . avec k i = card(di .Rt Rch )


di D

k i indique le nombre de fois o la connexion donneuse di traverse une


interface charge sur un routeur de son chemin de donnes.
Considrons lexemple 2 de la section prcdente. En valuant le critre
z2 avec chacune des solutions optimales obtenues avec le critre z1 , on
remarque que celles procurant la meilleure valeur pour z2 constituent un
sous-ensemble. En effet, si on calcule lexcdent libr sur chaque interface
charge avec les 2 solutions du problme P1 , on obtient :
pour la solution d1 . = 9, d2 . = 1, d3 . = 0 :
r1 .I1 = 0
r2 .I1 = 0
r2 .I2 = 6
r3 .I1 = 7
3.1. Rpartition de la bande passante 81

et pour la solution d1 . = 3, d2 . = 7, d3 . = 0 :
r1 .I1 = 0
r2 .I1 = 6
r2 .I2 = 0
r3 .I1 = 1
On constate quavec la solution d1 . = 3, d2 . = 7, d3 . = 0, la somme
des excdents est gale 7 alors quavec la solution d1 . = 9, d2 . = 1,
d3 . = 0, la somme des excdents est gale 13. On prfrera donc la
solution d1 . = 3, d2 . = 7, d3 . = 0.
On peut ce stade se demander si les solutions ainsi retenues sont ga-
lement optimales par rapport au critre z2 . Pour cela, il faut poser le pro-
blme P2 qui consiste dterminer les quantits d1 ., d2 . et d3 ., dcr-
ments des connexions donneuses d1 , d2 et d3 compensant les incrments
p1 . = 5 et p2 . = 5 des connexions receveuses p1 et p2 , et qui minimise le
critre z2 , la somme des excdents de bande passante libre au niveau de
chaque interface.
La connexion d1 passe par trois interfaces charges (r1 .I1 , r2 .I2 , r3 .I1 ),
la connexion d2 passe par deux interfaces charges (r1 .I1 , r2 .I1 ) et la
connexion d3 par une interface charge (r2 .I1 ). Les coefficients k i sont
donc : k1 = 3, k2 = 2 et k3 = 1. Par suite, on obtient :

Minimiser z2 = 3d1 . + 2d2 . + d3 .

d1 . + d2 . p1 . + p2 . r1 .I1 .


d2 . + d3 . p1 . r2 .I1 .





d . p . r .I .


1 2 2 2
d1 . p2 . r3 .I1 .




avec les contraintes
d . d1 .tobt
1




d2 . d2 .tobt
d3 . d2 .tobt







d1 ., d2 ., d3 . 0

Par consquent, on obtient :

Minimiser z2 = 3d1 . + 2d2 . + d3 .


d1 . + d2 . 10


d2 . + d3 . 1





d1 . 3






avec les contraintes d1 . 10
d2 . 10



d3 . 10








d1 ., d2 ., d3 . 0

Lalgorithme du simplexe modifi donne une solution unique :


d1 . = 3, d2 . = 7, d3 . = 0
82 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

qui correspond la solution optimale du problme P1 , solution qui est


prfre selon le critre z2 . Cette solution est donc optimale au regard des
deux critres.

3.1.8 Conclusion sur lutilisation des critres de minimisation globale


(z1 ) et de minimisation des excdents (z2 )

Notre approche consiste considrer le critre z1 , savoir minimiser la


quantit de bande passante globale libre, comme le critre prioritaire.
Si le problme admet une solution unique, on ne cherche pas utiliser
le critre z2 , qui permet de minimiser la somme des excdents de bande
passante sur chaque interface. En revanche, si le problme P1 (critre z1 )
admet plusieurs solutions, on value le critre z2 pour les diffrentes so-
lutions trouves pour ne retenir que les meilleures par rapport z2 .

3.2 Gestion cooprative de la QoS dans le systme NET-


QoS

Dans cette section, nous prsentons les extensions de larchitecture fonc-


tionnelle du systme NETQoS permettant de mettre en uvre une gestion
cooprative de la QoS et lintgration du modle prsent dans la section
prcdente 3.1.
Dans un premier temps (section 3.2.1 et 3.2.2), les principales modifica-
tions apporter aux classes et composants initiaux sont exposes. La sec-
tion 3.2.3 dcrit ensuite le processus de coopration.

3.2.1 Identification des connexions

Dans le diagramme de classe prsent Figure 3.4, la classe ConnectionId


contient deux attributs, les adresses IP sources et destination, et les ports
sources et destination. Pour prendre en compte une gestion cooprative
de la QoS, plusieurs autres informations doivent tre associes une
connexion.
La classe ConnectionId est donc spcialise en une classe CollaboratingCon-
nection possdant un attribut t_obt, dsignant le dbit obtenu par une
connexion, et un attribut R_t, dsignant la liste des routeurs traverss par
la connexion. Pour prendre en compte les informations spcifiques aux
deux types de connexions, la classe CollaboratingConnection est spcialise
en une classe GivingConnection et en une classe ReceivingConnection.
La classe GivingConnection dfinit une connexion donneuse possdant un
attribut , correspondant au dcrment. La classe ReceivingConnecion dfi-
nit une connexion receveuse possdant un attribut t_req, dsignant le dbit
requis pour cette connexion et un attribut , correspondant lincrment.
3.2. Gestion cooprative de la QoS dans le systme NETQoS 83

Figure 3.4 Classe CollaboratingConnection

Figure 3.5 Classes Modifies

3.2.2 Classe MoMe

Le MoMe introduit dans le chapitre 2 est le composant du systme NET-


QoS responsable de la supervision et de la collecte de donnes. La figure
3.5 est un diagramme de classe UML qui prsente une extension de ce
composant lui permettant dtre utilis pour une gestion cooprative de
la QoS.
Pour permettre un composant tel que lAPA de rcuprer les informa-
tions ncessaires la prise de dcision, le MoMe doit implmenter une in-
terface CollaborativeMoMe dans laquelle sont dfinies plusieurs mthodes :
84 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

getThroughput () : Cette mthode prend en paramtre un objet Collabora-


tingConnection et renvoie son dbit courant.
getRouterInterfaces () : Cette mthode prend en paramtre un objet Colla-
boratingConnection et renvoie une liste dinterfaces de routeurs traverses
par cette connexion.
getConnections () : Cette mthode prend en paramtre une interface de
routeur (objet RouterInterface) et renvoie une liste des connections (don-
neuses et receveuses) traversant cette interface.
getMargin () : Cette mthode prend en paramtre une interface de
routeur et renvoie sa marge, telle quelle a t dfinie prcdemment
(definition 3.2).

Ces mthodes, invoques notamment par le composant APA sur le MoMe


permettront de rcuprer les informations ncessaires pour le calcul de la
rpartition de la bande passante grce au modle prsent dans la section
prcdente. Dans la section 3.3, nous montrons comment ces mthodes
pourraient tre implmentes par le biais de certains outils et protocoles.

3.2.3 Mise en uvre du processus de coopration

Le processus de coopration doit tre initi lorsquune ou plusieurs


connexions receveuses voient leur dbit courant passer en dessous dun
certain seuil, infrieur au dbit requis pour cette connexion. Dans le sys-
tme NETQoS, il sagit donc dune violation de politique associe une
connexion.
Le diagramme prsent figure 3.6 rprsente les interactions et les mes-
sages changs entre les diffrents composants du systme NETQoS lors
dune violation de politique. Il sagit dune extension du diagramme pr-
sent au chapitre prcdent (Figure 2.11). Aprs avoir t notifi dune
violation de politique (message notification(pve)), lAPA rcupre via les
rpertoires de stockage de politiques, les informations et les politiques
oprationnelles de la connexion concerne par la violation de politique.
Le processus de coopration dbute ensuite et est dcrit dans le sous-
diagramme de squence appel "PrepareCollaborativeAdaptation" prsent
dans le paragraphe suivant (Figure 3.7).

3.2.4 Diagramme de squence pour la coopration

Pour chaque connexion receveuse qui voit son dbit passer en dessous
dun certain seuil infrieur au dbit requis par cette connexion, le compo-
sant APA stocke lvnement violation de politique (PolViolationEvent pve)
dans le composant Op_REPO. Cette action est effectue pour chaque v-
nement de politique pendant une priode T. A la fin de cette priode, le
composant OP_REPO contient lensemble des connexions receveuses qui
ont vu leur dbit passer en dessous dun certain seuil (contenues dans
lobjet PolViolationEvent). Le composant APA les rcupre en utilisant la
mthode getAllPolicyViolation() qui renvoie la liste des PolViolationEvent.
Puis, pour chaque connexion, le composant APA va rcuprer les infor-
3.2. Gestion cooprative de la QoS dans le systme NETQoS 85

Figure 3.6 Diagramme de squence Policy Violation

mations ncessaires la mise en uvre du modle de gestion coopra-


tive prsent dans la section 3.1 du chapitre. Pour cela, il invoque au-
prs du MoMe les mthodes dcrites au paragraphe 3.2.2. Pour chaque
connexion, le composant APA rcupre le dbit moyen courant associ
cette connexion receveuse (mthode getTroughput(cc)), puis lensemble
des interfaces de routeurs traverses par cette connexion (getRouterInter-
faces(cc)). Pour chaque interface, la mthode getConnections(ri), permet de
rcuprer lensemble des connexions donneuses qui traversent cette inter-
face et la mthode getMargin(ri) la marge associe cette interface.
Aprs avoir effectu ces diffrentes "boucles" (Figure 3.7), le composant
APA possdent maintenant lensemble des informations ncessaires la
86 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

Figure 3.7 Diagramme de squence pour une adaptation cooprative

mise en uvre du modle. Il peut donc calculer la quantit de bande


passante que chaque connexion donneuse doit donner pour satisfaire les
incrments des diffrentes connexions receveuses.

3.3 Outils et protocoles pour la rcupration des in-


formations

Pour implmenter les diffrentes mthodes du composant MoMe permet-


tant la rcupration des informations dcrites prcdemment, plusieurs
outils et protocoles sont envisageables. Nous les dcrivons ci-aprs ; mme
si nous navons pas directement contribuer cette facette de la problma-
tique, nous pensons que ces outils pourraient tre des briques de base
pour limplmentation des fonctions ncessaires dun organe de monito-
ring tel que le MoMe.

3.3.1 SNMP

SNMP (Simple Network Management Protocol) [CAS 90]. Il sagit dun


protocole qui permet aux administrateurs rseau de grer les quipements
du rseau et de diagnostiquer les problmes de rseau. Le systme de ges-
tion de rseau est bas sur deux lments principaux : un superviseur et
3.3. Outils et protocoles pour la rcupration des informations 87

des agents. Le superviseur est la console qui permet ladministrateur


rseau dexcuter des requtes de management. Les agents sont des enti-
ts qui se trouvent au niveau de chaque interface connectant lquipement
manag au rseau et permettant de rcuprer des informations sur diff-
rents objets.
Switchs, hubs, routeurs et serveurs sont des exemples dquipements
contenant des objets "grables" (plus classiquement appels "mana-
geables"). Ces objets peuvent tre des informations matrielles, des para-
mtres de configuration, des statistiques de performance et autres objets
qui sont directement lis au comportement en cours de lquipement en
question. Ces objets sont classs dans une sorte de base de donne appele
MIB ("Management Information Base"). SNMP permet le dialogue entre le
superviseur et les agents afin de recueillir les objets souhaits dans la MIB.
Larchitecture de gestion du rseau propose par le protocole SNMP est
donc fonde sur trois principaux lments :
les quipements manags (managed devices) sont des lments du r-
seau (ponts, switchs, hubs, routeurs ou serveurs), contenant des objets
de gestion (managed objects) pouvant tre des informations sur le ma-
triel, des lments de configuration ou des informations statistiques ;
les agents, cest--dire une application de gestion de rseau rsidant
dans un priphrique et charg de transmettre les donnes locales de
gestion du priphrique au format SNMP ;
les systmes de gestion de rseau (network management systems nots
NMS), cest--dire une console travers laquelle les administrateurs
peuvent raliser des tches dadministration.

Le protocole SNMP offre donc la possibilit de rcuprer des informations


sur diffrents quipements. Dans le cadre dun systme de gestion coop-
rative de la QoS, on pourait sen inspirer afin de rcuprer les informations
sur les routeurs (interfaces, marges, connexions traversantes...) ou sur les
entits Transport dextrmits (dbit dmission, dbit requis,...).

3.3.2 Traceroute

Traceroute est un outil de diagnostic des rseaux, prsent sur la plupart


des systmes dexploitation, permettant de dterminer le chemin suivi par
un paquet. La commande traceroute permet ainsi de dresser une cartogra-
phie des routeurs prsents entre une machine source et une machine cible.
La commande traceroute diffre selon les systmes dexploitation.
Traceroute appuie son fonctionnement sur le champ TTL des paquets IP.
En effet chaque paquet IP possde un champ dure de vie (TTL, Time To
Live) dcrment chaque passage dun routeur. Lorsque ce champ arrive
zro, le routeur, considrant que le paquet tourne en boucle, dtruit ce
paquet et envoie une notification ICMP lexpditeur.
Ainsi, Traceroute envoie des paquets un port UDP non privilgi, rput
non utilis (le port 33434 par dfaut) avec un TTL valant 1. Le premier
routeur rencontr va supprimer le paquet et renvoyer un paquet ICMP
donnant notamment ladresse IP du routeur ainsi que le temps de pro-
88 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

pagation en boucle. Traceroute va ainsi incrmenter squentiellement le


champ TTL, de manire obtenir une rponse de chacun des routeurs
sur le chemin, jusqu obtenir une rponse port ICMP non atteignable
(ICMP port unreachable) de la part de la machine cible.
Dans le cadre dun systme de gestion cooprative de la QoS, le protocole
Traceroute pourrait tre utilis afin de connaitre lensemble des routeurs
traverss par une connexion receveuse.

3.3.3 Protocoles de routage

Les protocoles de routage, notamment les protocoles tat de liens (link-


state protocol), permettent lchange dinformations entre les routeurs.
Chaque routeur tablit des relations dadjacence avec ses voisins imm-
diats en envoyant des messages intervalle rgulier. Chaque routeur com-
munique ensuite la liste des rseaux auxquels il est directement connect
par des messages propags de proche en proche tous les routeurs du
rseau. Lensemble de ces messages forme la base de donnes des liens
"Link-State Database" (LSDB), qui est identique pour tous les routeurs
participants. Chaque routeur utilise ensuite un algorithme pour dtermi-
ner la route la plus courte vers chacun des rseaux connus dans la LSDB.
En cas de changement de topologie, de nouveaux messages sont propags
de proche en proche.
Dans le cadre dun systme de gestion cooprative de la QoS, les proto-
coles de routage pourraient tre utiliss pour rcuprer les routes, et donc
les diffrents routeurs, emprunts par les connexions.

3.3.4 Fonctions de Monitoring dans ETP

Le protocole ETP prsent dans le chapitre 1, (section 1.4.3), est le pro-


tocole de Transport configurable sur lequel nous nous appuyons, pour
mettre en uvre une gestion cooprative de la QoS.
La structure modulaire de ETP permet notamment dinstancier des micro-
protocoles, sous la forme de composition de processing modules. On peut
envisager dinstancier des modules permettant de calculer ou de rcup-
rer, grce au feedback dETP, divers paramtres de QoS et donnes de
monitoring de niveau Transport, comme le dlai, le dbit, la gigue ou le
taux de pertes.
Dans le chapitre prcdent (section 2.3.4.3), nous avons montr comment
utiliser la structure modulaire de ETP pour instancier dans le plan de
Management un module ETP Agent Interface permettant de faire interagir
le composant ETP Agent du systme NETQoS avec une instance ETP en
cours dexcution.
De manire analogue, la figure 3.8 montre comment on peut instan-
cier dans le plan de Management des modules de monitoring qui, uti-
liss conjointement avec le module NETQoS, permettraient de centrali-
ser les valeurs des paramtres de QoS mesurs au sein du MoMe, par
exemple. Les modules "Monitoring Header" du plan de donnes (IN et
3.3. Outils et protocoles pour la rcupration des informations 89

Architectural and
Data Plan Data Plan
Behavioral
Adaptation Module
Monitoring header M1 Monitoring header M1

Monitoring header M2 Management Plan Monitoring header M1

Monitoring header Mn Monitoring M1 Monitoring header M1

MP out Monitoring M2 MP in

Monitoring Mn

Connection Performance Information

Figure 3.8 Fonctions de Monitoring dans ETP

OUT) servent encapsuler et dsencapsuler les ventuels enttes nces-


saires la mise en uvre du monitoring.

Conclusion

Dans ce chapitre, nous avons propos une contribution originale pour


llaboration dun systme de gestion cooprative de la QoS. Dans le
contexte des applications coopratives qui induit potentiellement des prio-
rits entre les connexions, un tel systme de gestion de la QoS peut tre
intressant pour rpondre au mieux aux pnuries de ressources induites
par le rseau ou son utilisation. Pour mettre en place un tel systme de
gestion cooprative, trois aspects sont prendre en compte : la rpartition
bande passante, la rcupration des donnes de supervision, et la mise en
uvre au niveau des htes dextrmit.
Dans la premire partie de ce chapitre, nous avons dfini puis formalis
les donnes ncessaires la rsolution du problme de rpartition de la
bande passante. Le principe est de donner une partie de la bande passante
certaines connexions au dtriment dautres. Pour dterminer la quantit
de bande passante que doivent librer les connexions pour satisfaire le be-
soin des connexions les plus prioritaires, notre approche consiste poser le
problme sous la forme dun problme de programmation linaire, cest-
-dire dune fonction objectif satisfaire sous contraintes. Nous avons par
ailleurs discut la pertinence et lutilisation de diffrents critres.
Dans la deuxime partie de ce chapitre, nous avons montr comment le
modle prsent pouvait tre intgr au systme NETQoS prsent au
chapitre 2. Les extensions du systme concernant les connexions et les
90 Chapitre 3. Gestion cooprative de la QoS au niveau Transport

services offerts par le composant de mesure et de monitoring (MoME)


ont t dcrits. Les diffrentes actions mettre en uvre au niveau du
composant de gestion de ladaptation (APA) pour collecter les donnes
ncessaires afin dutiliser le modle de calcul de la rpartition de la bande
passante ont t discutes.
Dans la dernire partie de ce chapitre, nous avons prsent diffrents l-
ments (outils et protocoles) concernant le deuxime aspect prendre en
compte pour mettre en place un systme de gestion cooprative de la
QoS : la rcupration des informations de supervision en utilisant notam-
ment des protocoles et des outils tels que SNMP, Traceroute, les protocoles
de routage tats de lien ou le protocole de Transport configurable ETP.
Les perspectives de ce travail sont nombreuses :
Stabilit des dbits. Lapproche cooprative que nous avons labore
sappuie sur lutilisation dun contrle de congestion et sur lhypothse
que le dbit des connexions restent stables sur une priode de temps
suffisamment longue. Si la dynamique des dbits des connexions ne
permet pas de vrifier cette hypothse, il faudra ventuellement le
prendre en compte pour modifier le modle.

Collecte dinformations. La rsolution du modle doptimisation sup-


pose de pouvoir rcuprer un certain nombre de donnes. Il faut
pouvoir valuer la faisabilit et le cot dune telle collecte dinforma-
tions. Si certaines informations ne sont pas rcuprables avec un cot
raisonnable, il faudra peut-tre envisager une modification du modle,
par exemple en relchant certaines contraintes dingalit.

Gestion des priorits. Une autre perspective concerne la gestion des


priorits, pour prendre en compte des connexions la fois donneuses
et receveuses, ou encore pour prendre en compte des priorits relatives
entre les connexions ; le but pourrait tre par exemple de permettre
des connexions donneuses de plus ou moins contribuer la coopration
en donnant un pourcentage de leur bande passante diffrent en fonction
de leur priorit.

Amlioration de lalgorithme du simplexe. Pour utiliser au mieux les


deux critres dfinis aux sections 3.1.6 et 3.1.7 (minimisation globale,
critre z1 et minimisation des excdents, critre z2), il serait utile de
pouvoir obtenir tous les sommets solution du problme. On pourrait
mme envisager de pouvoir trouver lensemble complet des solutions,
permettant ainsi daffiner les quantits de bande passante cdes par les
connexions, en relation avec les priorits par exemple. Cette perspective
porte sur lamlioration de lalgorithme bas sur le simplexe ou sur
lutilisation dun autre algorithme de rsolution permettant de trouver
lensemble complet de solutions.

Dsynchronisation de la dcision. Nos travaux pourraient galement


stendre pour couvrir la phase de dploiement et de mise en uvre de
la dcision et profiter dexprimentations pour affiner le modle de d-
cision. Par exemple, on pourra tudier linfluence de la synchronisation
3.3. Outils et protocoles pour la rcupration des informations 91

(ou de la dsynchronisation) de la dcision sur les htes dextrmits.


En effet, pour mettre en uvre cette approche de gestion cooprative,
on suppose quau mme instant, toutes les connexions de Transport
appliquent la dcision concernant la quantit de bande passante dont
elles vont maintenant bnficier. Sil y a dsynchronisation ou sil faut
un certain temps pour arriver un rgime permanent, il est sans doute
utile, voire ncessaire, de prendre en compte cette dynamique dans le
modle.

Dcision de collaboration. Enfin, dautres perspectives concernent la d-


cision de collaboration, comme par exemple dterminer partir de quel
seuil on doit commencer le processus de collaboration et comment on
le dtecte. De mme, lorsque la collaboration nest plus ncessaire, la
question de savoir comment lon revient la situation initiale se pose.

Dans le chapitre suivant, nous prsentons une tude de faisabilit de lap-


proche de gestion cooprative de la QoS, ralise avec le simulateur ns-2.
Outre la dmonstration de faisabilit, les simulations effectues ont per-
mis de soulever les questions relatives la stabilit des dbits (point 1 des
perspectives nonces ci-dessus).
Mise en uvre et valuation
de performance 4

Sommaire
4.1 Evaluation de performance de lAPA . . . . . . . . . . . . . 95
4.1.1 Spcification du contexte de mesure . . . . . . . . . . . . . 95
4.1.2 Mtriques mesures . . . . . . . . . . . . . . . . . . . . . . 97
4.1.3 Scnarios de mesures, rsultats et analyses . . . . . . . . . 97
4.1.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.2 Gestion cooprative de la QoS et rpartition de dbit . 104
Contrle de congestion utilis : TFRC . . . . . .
4.2.1 . . . . . . 105
Mise en uvre de lapproche . . . . . . . . . . .
4.2.2 . . . . . . 105
Etude de faisabilit - Scnarios simples . . . . .
4.2.3 . . . . . . 106
Etude de faisabilit - Scnarios plus complexes .
4.2.4 . . . . . . 109
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

D ans ce chapitre, nous prsentons les principaux rsultats des cam-


pagnes dvaluation de performance attenantes aux contributions
proposes dans ce mmoire. Ces valuations comportent deux volets, res-
pectivement relatifs aux propositions faites dans les chapitres 2 et 3. Nous
les introduisons ci-aprs.
Le chapitre 2 a prsent la proposition darchitecture laquelle nous avons
contribu dans le cadre du projet NETQoS. Rappelons que cette architec-
ture vise permettre (pour ce qui concerne directement nos travaux) une
gestion adaptative des protocoles de Transport configurables pour optimi-
ser la QoS requise par des applications distribues dans un environnement
de rseaux htrognes. La premire partie de ce chapitre (section 4.1) sat-
tache valuer les performances du composant impliqu dans la dcision
(APA) auquel nous avons plus spcifiquement contribu. Les principes
dimplmentation de ce composant et de ses sous-composants sont va-
lus sous langle de plusieurs mtriques, notamment lies au temps de
service des requtes faites lAPA. Lobjectif est dvaluer la capacit de
lAPA rsister au facteur dchelle vis--vis du nombre de requtes
traiter.
Dans le chapitre 3, nous nous sommes intresss la dcision dadap-
tation de la QoS au niveau Transport, par le biais dune proposition de

93
94 Chapitre 4. Mise en uvre et valuation de performance

gestion dite collaborative. Le problme de la dcision, qui sinscrit pleine-


ment dans le rle de lAPA, nous a amens dfinir un modle dopti-
misation permettant de rpartir de manire cooprative les ressources en
bande passante attribues aux connexions Transport considres. La se-
conde partie de ce chapitre (section 4.2) prsente les mcanismes mis en
uvre pour implanter la dcision prise grce au modle. Nous nous atta-
chons galement montrer la pertinence et lefficacit du modle propos
dans diffrents scnarios de collaboration.
Finalement, nous concluons sur les valuations effectues, et nous en d-
gageons des perspectives pour conforter nos propositions.
4.1. Evaluation de performance de lAPA 95

4.1 Evaluation de performance de lAPA

LAutomated Policy Adaptor (APA) est lentit centrale du systme de


contrle de ladaptation dfini dans le projet NETQoS (Figure 4.1). Partant
de politiques dynamiques stockes par les acteurs dans le rpertoire POLD
(via lAPM), le rle de lAPA est de dcider et de faire appliquer les poli-
tiques oprationnelles, en particulier au niveau Transport, pour permettre
au systme de communication de fournir une QoS optimise. Pour cela,
lAPA sappuie sur le composant de monitoring et de mesures (MoMe),
charg dobserver et de mesurer lvolution du contexte applicatif et r-
seau, ainsi que lefficience des politiques oprationnelles. Les requtes que
reoit lAPA proviennent directement du composant CM (Context Mana-
ger) du MoMe. Ces requtes sont soient des requtes de provisionnement
de (nouvelles) politiques, soient des requtes dadaptation de politiques
existantes lorsque celles-ci ne rpondent pas aux objectifs de QoS dduites
des politiques exprimes par par acteurs.

Figure 4.1 Les entits principales du systme NETQoS

Le but de cette section est dvaluer la rsistance de lAPA au facteur


dchelle vis--vis du nombre de requtes de provisionnement et dadap-
tation traiter. Les mesures ont t effectues sur une machine de type
Dual Core Xeon 3050/2.13Ghz - 2GiB de RAM.

4.1.1 Spcification du contexte de mesure

LAPA est compos de trois composants principaux, le PDM (Policy De-


cision Manager), le PAM (Policy Adaptation Manager) et le PEM (Policy
Enforcement Manager), dont limplmentation JAVA est base sur lutili-
sation de "Threads" (mono and multi-threading).
Tel que prsent dans le chapitre 2, section 2.2.3.2.2, le PDM, qui est charg
de grer les requtes de provisionnement, est divis en trois composants
actifs. Dans les paragraphes suivants, nous rappelons les fonctionnalits
de chacun de ces composants en prcisant la nature des interaction en-
96 Chapitre 4. Mise en uvre et valuation de performance

trantes, la nature des interactions sortantes et lusage du multi-threading


ou de files dattentes dans leur implmentation.
Le PDMNotificationManager traite les vnements de type lancement
dapplication (ApplicationLaunch event) venant du Context Manager
(CM), rcupre les politiques intermdiaires correspondantes dans le r-
pertoire (POLD) et les transmet au PDMWorkerManager.
Il prend en entre les vnements venant du Context Manager.
Il retourne en sortie la politique intermdiaire fournir.
Il nutilise pas le multi-threading : une file dattente de longueur infi-
nie est utilise pour stocker les vnements venant du Context Manager.

Le PDMWorkerManager prend la dcision de provisionnement ncessaire


et la transmet au PDMDispatcher.
Il prend en entre la politique intermdiaire provisionnner.
Il retourne en sortie la politique oprationnelle dployer.
Il utilise le multi-threading : un thread PDMWorker est ainsi cr pour
chaque politique intermdiaire venant du PDMNotificationManager.

Le PDMDispatcher est charg des interactions avec le PEM afin de d-


ployer la politique oprationnelle. Il stocke galement la politique dans le
POLD, et rend la politique active dans le POLD.
Il prend en entre la politique oprationnelle dployer.
Il retourne en sortie cette mme politique oprationnelle.
Il nutilise pas le multi-threading : une file dattente de longueur infinie
est utilise pour stocker la politique oprationnelle venant du PDM-
WorkerManager.

De manire analogue au PDM, le gestionnaire de ladaptation des poli-


tiques, le PAM, qui est charg des requtes dadaptation, est divis en
trois composants actifs pour lesquels les mmes choix ont t effectus
concernant lutilisation du multi-threading et les files dattente.
Le PAMNotificationManager traite les vnements de type violation de
politique (PolicyViolation event) venant du Context Manager, rcupre
les politiques (intermdiaire et oprationnelle) dans le rpertoire POLD,
et les transmet au PAMWorkerManager.
Le PAMWorkerManager prend les dcisions dadaptation ncessaires
et les transmet au PAMDispatcher.
Le PAMDispatcher est charg des interactions avec le PEM afin de
dployer la nouvelle politique oprationnelle, et de la stocker dans le
POLD.

Le PEM est compos principalement du gestionnaire de lapplication des


politiques, appel PEMEnforcementManager. En fonction des diffrents
niveaux de politiques oprationnelles dployer (niveau Transport, R-
seau,. . .), le PEMEnforcementManager, dlgue le dploiement de la poli-
tique pour chacun de ces niveaux vers le IPolicyEnforcer correspondant.
Pour chaque niveau, par exemple le niveau Transport dans notre cas :
il prend en entre la politique oprationnelle dployer ;
il retourne en sortie la politique oprationnelle dployer ;
il nutilise pas le multi-threading : une file dattente de longueur infinie
4.1. Evaluation de performance de lAPA 97

est utilise pour stocker la politique oprationnelle venant du PDMWor-


kerManager.

4.1.2 Mtriques mesures

Le comportement de lAPA est dclench par la rception dvnements


venant du Context Manager tel que lvnement ApplicationLaunchEvent
dans le cas dun provisionnement et dun vnement PolicyViolationEvent
lorsquune adaptation est requise.
Pour valuer les performances de lAPA, deux mtriques principales ont
t observes pour diffrentes valeurs de taux darrive des vnements
ApplicationLaunchEvent et PolicyViolationEvent :
le temps de service par requte (correspondant chacune un vne-
ment) ;
la longueur des files dattente dvnements pour les composants in-
ternes.

4.1.3 Scnarios de mesures, rsultats et analyses

Deux types de scnarios ont t dfinis et raliss :


le premier vise valuer lAPA vis--vis des requtes de provisionne-
ment rsultant de la rception des vnements ApplicationLaunchEvent ;
dans ces scnarios, seuls le PDM et le PEM sont impliqus.
le second vise valuer lAPA vis--vis des requtes dadaptation rsul-
tant de la rception des vnements PolicyViolation ; dans ces scnarios,
seuls le PAM et le PEM sont impliqus.

4.1.3.1 Evaluation de lAPA vis--vis des requtes de provisionnement

Cette section prsente les performances de lAPA en termes de temps de


traitement des requtes et dvolution des files dattente internes. Le taux
darrive des requtes ApplicationLaunchEvent varie de 20 vnements/s
200 vnements/s.
Les courbes des figures 4.2, 4.3 et 4.4 montrent le temps de traitement des
requtes par le gestionnaire de dcision (PDM) et le gestionnaire dap-
plication (PEM) des politiques. Les courbes de la figure 4.5 prsentent
lvolution des files dattente des diffrents composants de lAPA qui sont
impliqus dans le processus de provisionnement, cest--dire le PDM No-
tification Manager, le PDM Dispatcher et le PEM.
APA : Temps de traitement des requtes de provisionnement
Trois types de courbes sont prsents :
les courbes de la figure 4.2 prsentent lhistogramme du pourcentage de
requtes servies par intervalle de temps, pour diffrents taux darrive
variant de 20 200 vnements/s ;
les courbes de la figure 4.3 prsentent le temps de transit des requtes,
pour diffrents taux darrive variant de 20 200 vnements/s ;
98 Chapitre 4. Mise en uvre et valuation de performance

les courbes de la figure 4.4 prsentent la valeur moyenne du temps de


transit dune requte en fonction du taux darrive variant de 20 200
vnements/s.

(a) = 20 events/s (b) = 40 events/s

(c) = 50 events/s (d) = 70 events/s

(e) = 100 events/s (f) = 200 events/s


Figure 4.2 T-APA : Histogramme du % de requtes de provisionnement servies par
intervalle de temps

APA : Evolution de la longueur des files dattente


4.1. Evaluation de performance de lAPA 99

(a) = 20 events/s (b) = 40 events/s

(c) = 50 events/s (d) = 70 events/s

(e) = 100 events/s (f) = 200 events/s


Figure 4.3 T-APA : Temps de transit pour une requte de provisionnement

La figure suivante 4.5 montre lvolution des diffrentes files dattente g-


res dans lAPA lorsquil doit traiter des requtes de provisionnement.
Analyse
Deux comportements diffrents sont observs en fonction du taux darri-
ve des vnements ApplicationLaunchEvent :
De 20 39 vnements/s, lAPA nest pas charg (Figure 4.2). Les
meilleures performances sont obtenues et les files dattentes restent
vides pour tous les composants impliqus. Par exemple, pour un taux
darrive de 20 vnements/s, presque 60% des requtes sont servies
en moins de 50 ms qui est la valeur moyenne du temps inter-arrives
100 Chapitre 4. Mise en uvre et valuation de performance

Figure 4.4 T-APA : Temps de transit moyen dune requte de provisionnement vs.
taux darrive

Figure 4.5 APA : Evolution de la longueur des files dattente en fonction du temps

des requtes.

Lorsque le taux darrive dpasse les 40 requtes/s, lAPA commence


tre surcharg :
Ceci est montr par laugmentation progressive des files dattente in-
terne (Figure 4.5).
On peut remarquer sur la figure 4.3 que lAPA peut rsister un
nombre importants de requtes par seconde seulement pendant une
priode courte (moins dune seconde). Cela sexplique par lutilisa-
tion massive du multi-threading dans le processus de dcision (un
PDMWorker est cr par requte). Aprs la cration dun nombre
donn de threads, la JVM nest pas capable de crer de nouveau
threads et le systme est bloqu jusqu ce que les anciens threads
meurent.
4.1. Evaluation de performance de lAPA 101

Remarquons enfin que les histogrammes prsents sur la figure 4.3 et les
temps moyens de transit des requtes de provisionnement prsents figure
4.4 ne prennent pas en compte les valeurs mesures aprs le blocage.

4.1.3.2 Evaluation de lAPA vis--vis des requtes dadaptation

Cette section prsente les performances de lAPA vis--vis du temps de


traitement des requtes dadaptation et de lvolution des files dattente
internes. Le taux darrive des requtes de violation de politique Policy-
ViolationEvent varie toujours de 20 vnements/s 200 vnements/s.
Les courbes des figures 4.6, 4.7 et 4.8 montrent (pour le PAM et le PEM) les
temps de service moyen des requtes. Les courbes de la figure 4.9 prsente
lvolution de la file dattente des diffrents composants de lAPA qui sont
impliqus dans le processus dadaptation, cest--dire le PAM Notification
Manager, le PAM Dispatcher et le PEM.
APA : Temps de traitement des requtes dadaptation
Trois types de courbes sont prsents :
la figure 4.6 prsente lhistogramme du pourcentage de requtes servies
par intervalle de temps, pour diffrents taux darrive de requte ;
la figure 4.7 prsente le temps de transit des requtes, pour diffrents
taux darrive de requte ;
la figure 4.8 prsente la valeur moyenne du temps de transit dune
requte en fonction du taux darrive de requte.

APA : Evolution de la longueur des files dattente


La figure suivante 4.9 montre lvolution des diffrentes files dattente g-
res dans lAPA lorsquil doit traiter des requtes dadaptation.

Analyse
Comme pour les mesures concernant les requtes de provisionnement,
deux comportements diffrents sont observs en fonction du taux darri-
ve des vnements PolicyViolationEvent :
de 20 39 vnements/s, lAPA nest pas charg. Les meilleures perfor-
mances sont obtenues et les files dattentes restent vides pour tous les
composants impliqus (Figure 4.9). Par exemple, pour un taux darrive
de 20 vnements/s, plus de 75% des requtes sont servies en moins de
50 ms ;

lorsque le taux darrive dpasse les 40 requtes/s (voir les figures avec
un de 50, 70, 100, 200), lAPA commence tre surcharg :
ceci est montr par laugmentation progressive des files dattente in-
terne (Figure 4.9) ;
de manire analogue aux mesures effectues pour les requtes de
provisionnement, on peut remarquer sur la figure 4.7 que lAPA peut
rsister larrive dun nombre important de requtes par seconde
pendant une priode donne puis que le dlai de transit augmente
trs rapidement. Cela sexplique nouveau par lutilisation massive
102 Chapitre 4. Mise en uvre et valuation de performance

(a) = 20 events/s (b) = 40 events/s

(c) = 50 events/s (d) = 100 events/s


Figure 4.6 APA : Histogramme du % de requtes dadaptation servies par intervalle
de temps

du multi-threading dans le processus de dcision (un PAM worker


cr par requte). Aprs la cration dun nombre donn de threads,
la JVM nest plus capable de crer de nouveaux threads et le systme
est bloqu jusqu ce que les anciens threads meurent.

Remarquons enfin que les histogrammes prsents sur la figure 4.7 et les
temps moyens de transit des requtes dadaptation prsents figure 4.8 ne
prennent pas en compte les valeurs mesures aprs le blocage.

4.1.4 Conclusions

Cette section a prsent une campagne de mesures visant valuer les


choix dimplmentation du composant de dcision propos dans le projet
NETQoS (lAPA). Lobjectif tait dvaluer la rsistance au facteur dchelle
de lAPA face aux requtes de provisionnement et dadaptation suscep-
tibles dtre reues.
Plusieurs mtriques lies au temps de service de lAPA ont t analy-
ses afin de valider en particulier lusage propos du multi-threading.
Les mesures prsentes font apparatre que lAPA est capable de trai-
ter dans un dlai acceptable un nombre donn (de lordre de 40) de re-
qutes de provisionnement ou adaptation par seconde. Au del, lAPA est
toujours capable de traiter les requtes mais seulement pendant une trs
4.1. Evaluation de performance de lAPA 103

(a) = 20 events/s (b) = 40 events/s

(c) = 50 events/s (d) = 100 events/s


Figure 4.7 PAM : Temps de transit pour une requte dadaptation

Figure 4.8 APA : Temps de transit moyen pour une requte dadaptation vs. taux
darrive

courte priode. Ce phnomne dcoule dune utilisation massive du multi-


threading, qui conduit au blocage du systme en raison des limitations de
la JVM. Une solution tudier pourrait tre de mettre en place une so-
lution hybride de mono et multi-threading, pour maintenir le nombre de
threads PDM/PAM Worker crs sous une valeur donne.
Dans le cadre dune activit de groupe telle que celles cibles par nos
104 Chapitre 4. Mise en uvre et valuation de performance

Figure 4.9 T-APA : Evolution de la longueur des files dattente

travaux, bien que nous nayons pas men ltude de faon formelle, le
nombre restreint de participants et la nature ferme de lenvironnement
rseau permettent denvisager des performances acceptables de lAPA vis-
-vis du nombre de requtes de provisionnement ou dadaptation.
La suite de ce chapitre prsente les rsultats de la campagne dvaluation
de performance attenante notre proposition de gestion cooprative de la
QoS.

4.2 Gestion cooprative de la QoS et rpartition de d-


bit

La premire partie de ce chapitre a permis dvaluer les principes dimpl-


mentation dun des composants du systme de gestion de la QoS dans les
rseaux autonomes, lAPA, tel que propos dans projet NETQoS. Comme
nous lavons montr au chapitre 3, cest par ce composant que la dcision
de gestion collaborative peut tre prise, grce limplmentation du mo-
dle doptimisation permettant daugmenter la QoS dune connexion au
dtriment dune ou plusieurs autres connexions.
Dans la suite de ce chapitre, nous cherchons valuer la pertinence et lef-
ficacit du mcanisme de gestion collaborative dcrit au chapitre 3. Pour
cela, nous prsentons dabord deux mises en uvre possibles de lap-
proche de gestion de collaboration propose au niveau Transport. Ensuite,
nous prsentons la campagne dvaluation organise en deux parties : la
premire est une tude de faisabilit mene dans un contexte limit ; la
deuxime sappuie sur une topologie plus complexe en termes de nuds
et de connexions, et sappuie sur la mthode doptimisation propose au
chapitre 3.
4.2. Gestion cooprative de la QoS et rpartition de dbit 105

4.2.1 Contrle de congestion utilis : TFRC

Comme explicit en section 3.1.3 du chapitre 3, notre approche de rpar-


tition de la QoS sappuie sur lhypothse de la mise en uvre dun m-
canisme de contrle de congestion, qui de manire classique vite leffon-
drement du rseau et permet denvisager une relative stabilit des dbits
des connexions sur des priodes de temps significativement longues.
Le contrle de congestion que nous avons retenu pour mettre en uvre la
coopration des connexions de Transport est le mcanisme TFRC pour les
raisons suivantes :
TFRC est un mcanisme de contrle de dbit linitiative de lmet-
teur bas sur un modle. Il a t conu pour minimiser les variations
brusques de dbit afin de rpondre aux besoins des applications mul-
timdias. Il permet galement de respecter les flux TCP vis--vis de
lutilisation de la bande passante ;
TFRC est un mcanisme de contrle de congestion bas dbit qui offre
une estimation de la bande passante pour les diffrentes connexions
que nous allons pouvoir utiliser.

Lmetteur ajuste le dbit dmission des paquets en fonction de rapports


(appels feedback) envoys par le rcepteur. En fonction des informations
contenues dans un feedback, lmetteur calcule le dbit dmission. Dans
lalgorithme du mcanisme TFRC, la bande passante pour une connexion
est estime explicitement par la formule (4.1) suivante :

s
TFRC = q q (4.1)
2bp 3bp 2
R 3 + t RTO (3 8 ) p (1 + 32p )

avec TFRC le dbit en octets/s, s la taille dun paquet en octets, R le RTT


en secondes, t RTO la valeur du timer de retransmission en secondes, p
[0..1] le taux dvnements de pertes calcul par lmetteur, b le nombre
maximal de paquets acquitts par un acquittement TCP.

4.2.2 Mise en uvre de lapproche

Lapproche de gestion collaborative propose dans le chapitre 3 est base


sur la capacit des entits de Transport effectuer des incrments + (pour
les connexions receveuses) ou des dcrments (pour les connexions
donneuses) sur leur dbit dmission.
Nous avons test deux approches pour aboutir ces incrments et dcr-
ments.
La premire approche repose sur un algorithme consistant modifier le
dbit obtenu par la formule (4.1) en ajoutant ou retranchant les quantits
correspondantes. Ainsi, pour une connexion receveuse pk , le dbit calcul
par le mcanisme TFRC, donn par lquation 4.1 est not pk .TFRC. Ce
dbit est ensuite augment de la quantit pk . requise par la connexion.
De la mme manire, une connexion donneuse dk dont le dbit est not
dk .TFRC, sera diminu de la quantit dk ..
106 Chapitre 4. Mise en uvre et valuation de performance

Le dbit des connexions est donc donn par :


pk .TFRC + pk . o pk est une connexion receveuse
dk .TFRC dk . o dk est une connexion donneuse.
Dans la suite, nous dsignons par contrle de congestion collaboratif ce nou-
veau mcanisme. La sections 4.2.3 suivante et la premire partie de la sec-
tion 4.2.4 prsentent les rsultats de mesures attenant la mise en uvre
de ce mcanisme.
La deuxime approche teste pour pour aboutir des incr-
ments/dcrments sur des connexions receveuses/donneuses, ne repose
pas sur une modification de TFRC mais sur la mise en uvre dun
contrle de dbit (Shaper) au-dessus de TFRC avec pour valeur seuil les
valeurs obtenues grce notre modle doptimisation. Les rsultats de la
mise en uvre de cette approche sont prsents en section 4.2.4.3.

4.2.3 Etude de faisabilit - Scnarios simples

Afin dillustrer la mise en uvre du contrle de congestion collabora-


tif, nous considrons plusieurs scnarios mettant en jeu uniquement deux
connexions qui collaborent en prsence dautres connexions non col-
laborantes car elles ne participent pas lactivit. On y considre en
particulier une connexion receveuse qui requiert un incrment de et une
connexion donneuse sur laquelle on applique un dcrment de , de
manire ce que la collaboration se ralise.
Ces scnarios simples ne requirent pas lutilisation de la mthode dopti-
misation propose dans le chapitre 3.
Les scnarios ont t conus pour tudier deux points particuliers :
linfluence de la localisation des interfaces charges que nous appelle-
rons dans cette partie "goulots dtranglement" ;
labsence deffet perturbateur sur les connexions ne participant pas
lactivit collaborative.
Enfin, afin dviter les problmes lis la dynamique de TFRC, les p-
riodes de simulations sont volontairement trs importantes.

4.2.3.1 Prsentation des scnarios

Nous avons considrs trois scnarios :


Dans le premier scnario, les deux connexions qui collaborent (une
connexion receveuse et une connexion donneuse) sont excutes de fa-
on ce quelles suivent la mme route travers le rseau. Afin dassurer
cette proprit, nous attribuons ces connexions la mme source ainsi que
la mme destination, et nous supposons un routage statique.
Le second scnario, qui vise tendre le domaine de validit de notre ap-
proche, considre deux sources de trafic distinctes mettant destination
dune mme machine. Dans ce scnario, nous veillons ce que le goulot
dtranglement (bottleneck) pour ces connexions soit situ sur la portion
commune de leurs routes respectives.
4.2. Gestion cooprative de la QoS et rpartition de dbit 107

Enfin, le troisime scnario permet de mettre en vidence les limites de va-


lidit du mcanisme propos. En effet, dans ce scnario, les deux sources
collaborantes (la connexion donneuse et la connexion receveuse) ne par-
tagent plus le mme goulot dtranglement . Leffet du mcanisme sur
les autres connexions prsentes est tudi permettant ainsi de tirer les
conclusions quant aux hypothses de bon fonctionnement du mcanisme.
Dans chacun des scnarios, les routeurs constituant les goulots dtrangle-
ment sont reprsents par un cercle avec un point noir au centre.

4.2.3.2 Rsultats et Analyse

Figure 4.10 Scnario I : Flux suivant la mme route

Scnario 1. Les rsultats obtenus pour le premier scnario sont prsents


sur la Figure 4.10. Dans ce scnario, les deux connexions collaborantes
partagent la mme route travers le rseau. Elles sont en concurrence
avec dautres connexions de telle sorte que lun des routeurs situes sur le
chemin de donnes soit en tat de congestion.
Cette premire tude vise montrer dans un premier temps la faisabilit
de lapproche. Si la topologie utilise est spcifique, on peut nanmoins
remarquer que beaucoup dapplications existantes, telles que la vido-
confrence, prsentent une configuration analogue (flux audio et vido
priorits relatives).
Sur la courbe Figure 4.10, on peut observer que chacune des quatre
connexions en concurrence obtient en rgime stationnaire une part de la
bande passante totale disponible de 490Kbps environ entre les instants
3 et 10. La priode collaborative intervient entre les instants 10 et 50.
Dans cet intervalle, il est remarquable que la connexion receveuse obtient
plus de ressources (550Kbps) que la connexion donneuse (430Kbps). De
plus, il apparait que cette collaboration na aucune incidence sur les deux
autres connexions prsentes, qui conservent chacune une part de bande
passante de 490Kbps comme prcdemment. Enfin, une fois la priode de
collaboration termine, lalgorithme standard du contrle de congestion
permet nouveau lobtention dun dbit denviron 490Kbps pour chaque
connexion.
108 Chapitre 4. Mise en uvre et valuation de performance

Figure 4.11 Scnario II : Flux de sources distinctes

Scnario 2. Les rsultats obtenus pour le second scnario sont prsen-


ts sur la Figure 4.11. Dans ce scnario, les deux connexions collaborantes
proviennent de sources diffrentes. Elles sont en concurrence avec dautres
connexions de telle sorte que lun des routeurs situs sur la partie com-
mune du chemin de donnes soit en tat de congestion.
Une premire partie de ltude entre les instants 10 et 15 sur la courbe Fi-
gure 4.11 vise montrer, quen labsence de flux concurrents, le contrle de
congestion collaboratif est possible entre deux flux provenant de sources
diffrentes et partageant un routeur congestionn. Dans un second temps,
un premier flux non collaboratif est introduit ; la prsence dune priode
de collaboration entre les instants 30 et 40 na aucun effet sur le flux non
collaboratif qui obtient toujours une part quitable de la bande passante
disponible. Enfin, larrive dun nouveau flux pendant la priode de col-
laboration linstant 40 a pour effet de rduire le dbit de toutes les
connexions prsentes. On peut noter que les connexions non collaboratives
ont un dbit inchang pendant lintervalle 40-50. Enfin, les connexions
collaboratives ragissent larrive du nouveau flux dans le systme en
rduisant leur dbit de faon laisser place au nouvel arrivant ; elles
conservent cependant les priorits propres leur collaboration.
Scnario 3. Les rsultats obtenus pour le troisime scnario sont prsen-
ts sur la Figure 4.12. Dans ce scnario, les deux connexions collaborantes
proviennent de sources diffrentes et sont en concurrence avec dautres
connexions de telle sorte que les routeurs congestionns ne soient pr-
sent plus situs sur la partie commune du chemin de donnes.
Sur le courbe prsente Figure 4.12, un premier intervalle de collabora-
tion entre les instants 10 et 15 rappelle les rsultats obtenus prcdem-
ment lorsque le goulot dtranglement est partag. Nanmoins, larri-
ve dun premier flux non collaboratif linstant 20 a pour effet de d-
placer le goulot dtranglement de la partie haute du rseau. Ainsi, les
connexions collaboratives ne partagent plus de goulot dtranglement
aprs linstant 20. La phase de collaboration entre les instants 30 et 50 per-
met de voir, dans un premier temps, que la connexion non collaborante
est affecte par le comportement agressif de la connexion de forte priorit.
4.2. Gestion cooprative de la QoS et rpartition de dbit 109

Figure 4.12 Scnario III : Flux de sources distinctes, bottleneck distincts

De ce fait, le partage des ressources nest plus quitable. De plus, larrive


dune nouvelle connexion non collaborante partageant le mme goulot
dtranglement montre que le comportement agressif de la connexion de
forte priorit affecte toutes les autres connexions.

4.2.3.3 Conclusion

Ces trois scnarios montrent la faisabilit du mcanisme sur des priodes


de collaboration longues, sans dpasser toutefois la dizaine dheures. Cette
chelle de temps permet dillustrer le processus de coopration en faisant
abstraction des fluctuations des dynamiques temporelles plus leves.
Les goulots dtranglement permettent didentifier les connexions qui
doivent collaborer. Il ressort clairement que le mcanisme de collabora-
tion peut tre effectif sans perturber les connexions non collaborantes.
Dans la section suivante, nous tudions le phnomne de coopration sur
des chelles de temps plus courtes, et sur une topologie de connexions
plus complexe, en appliquant la mthode de calcul optimis des dcr-
ments propose dans le chapitre 3.

4.2.4 Etude de faisabilit - Scnarios plus complexes

Les simulations prsentes dans cette section diffrent des prcdentes en


plusieurs points.
Dabord, la topologie rseau est plus complexe : elle prsente un
nombre de nuds plus important ; nous considrons toujours une unique
connexion receveuse mais plusieurs connexions potentiellement don-
neuses.
Ensuite, nous ne nous intressons pas ici linfluence de la coopration
sur les connexions non collaborantes ou la localisation des points de
congestion. Il sagit en effet de vrifier le comportement du contrle de
congestion collaboratif sur des chelles de temps courtes lorsquon injecte
110 Chapitre 4. Mise en uvre et valuation de performance

les incrments et dcrments donns par le modle doptimisation pour


plusieurs connexions donneuses.
Enfin, nous cherchons exprimenter les deux mthodes proposes pour
mise en uvre du contrle de congestion collaboratif :
soit par la modification du mcanisme TFRC pour prendre en compte la
possibilit daugmenter ou de diminuer le dbit de la quantit voulue,
cest--dire la mme modification que pour les simulations prcdentes
sur des priodes de temps plus longues ;
soit utilisation dun mcanisme TFRC non modifi mais combin un
mcanisme de contrle de dbit, de type Shaper.

Nous prsentons dabord le scnario avec la topologie rseau et les


connexions mises en jeu, puis nous prsentons les rsultats obtenus.

4.2.4.1 Prsentation du scnario

La topologie rseau utilise en simulation est prsente figure 4.13. Le lien


entre les nuds n2 et n3 a une capacit de 2.4 Mbits/s. La capacit est de
2 Mbits/s pour tous les autres liens.

Figure 4.13 Topologie rseau de la simulation ns-2

On considre sept connexions dont les caractristiques sont donnes pour


chacune par : le type de la connexion (donneuse ou receveuse), lidentit
des nuds source ou destination), la route emprunte et le dbit moyen
requis. Toutes les sources sont supposes mettre un dbit constant.
4.2. Gestion cooprative de la QoS et rpartition de dbit 111

Connexion p1 Connexion d5
type : receveuse type : donneuse
source : n0 source : n14
destination : n4 destination : n4
route : n1 , n2 , n3 route : n16 , n17 , n3
dbit moyen : 1.2 Mbits/s dbit moyen : 0.1 Mbits/s
Connexion d2 Connexion d6
type : donneuse type : donneuse
source : n7 source : n15
destination : n11 destination : n4
route : n9 , n2 , n3 , n10 route : n16 , n17 , n3
dbit moyen : 0.8 Mbits/s dbit moyen : 0.1 Mbits/s
Connexion d3 Connexion d7
type : donneuse type : donneuse
source : n8 source : n18
destination : n12 destination : n4
route : n9 , n2 , n3 , n10 route : n16 , n17 , n3
dbit moyen : 0.8 Mbits/s dbit moyen : 0.1 Mbits/s
Connexion d4
type : donneuse
source : n13
destination : n4
route : n16 , n17 , n3
dbit moyen : 0.1 Mbits/s
Daprs les dbits des diffrentes connexions donns ci-dessus et les capa-
cits de chaque lien, on constate aisment que la seule interface charge
est linterface du routeur allant de n2 n3 . Celle-ci a en effet une capa-
cit de 2,4 Mbits/s mais doit couler un total de 2,8 Mbits rsultant de la
traverse des paquets :
de deux connexions donneuses, d2 et d3 , qui obtiennent chacune un
dbit moyen de 0.8 Mbits/s correspondant au dbit requis ;
de la connexion receveuse (p1 ), qui obtient un dbit de 0.8 Mbits/s
(pour 1,2 Mbits/s requis).

On se place donc dans lanalyse qui suit dans le cas o la connexion rece-
veuse (p1 ) rclame un incrment de p1 . = 0.4Mbits/s

4.2.4.2 Rsultats et Analyse

Dans le scnario considr, lalgorithme doptimisation prsent dans le


chapitre 3 produit les deux solutions triviales suivantes :
d2 = 0.4 ; d3 = 0
d3 = 0.4 ; d2 = 0
ce qui signifie que les quantits de dbit que les connexions donneuses d2
et d3 vont devoir cder sont 0 et 0.4, ou inversement.
En dautres termes, soit la connexion d2 diminue son dbit de 0.4 Mbits/s
et la connexion d3 garde son dbit courant, soit la connexion d3 diminue
son dbit de 0.4 Mbits/s et la connexion d2 garde son dbit courant.
112 Chapitre 4. Mise en uvre et valuation de performance

La figure 4.14 prsente les rsultats obtenus pour la mise en uvre de la


solution, d2 = 0.4 ; d3 = 0. Le temps en seconde est reprsent en abscisse
et le dbit en Mbits/s est reprsent en ordonne.
La collaboration ne concernant que les connexions p1 , d2 et d3 , les dbits
des autres connexions ne sont pas reprsents.
Jusqu linstant 400, on constate que les trois flux en concurrence se par-
tagent quitablement la bande passante, avec un dbit de 0.8 Mbits/s. A
partir de linstant 400, la collaboration dbute. La connexion receveuse p1
voit son dbit augmenter jusqu une valeur proche de 1.2 Mbits/s, tandis
que le dbit de la connexion d2 est diminu de 0.4 Mbits/s. La connexion
d3 obtient toujours une bande passante de 0.8 Mbits/s. La collaboration
cesse linstant 600 et chacune des trois connexions retrouve un dbit
quitable de 0.8 Mbits/s.

Figure 4.14 Dbit TFRC modifi

Les courbes prsentes sur la figure 4.15 permettent de conforter le rsul-


tat prcdent. Elles rsultent du mme scnario exprimental mais pour
lequel les dbits moyens obtenus ont t lisss en effectuant une moyenne
fentre glissante afin de supprimer les variations brusques des dbits
qui ne sont pas reprsentatives.
Les deux courbes prcdentes (figures 4.14 et 4.15) montrent que le mca-
nisme de contrle de congestion collaboratif fonctionne sur des priodes
de temps plus restreintes que celles prsentes dans la section 4.2.3.
Cependant, deux phnomnes sont remarquer. Dune part, laugmenta-
tion de dbit obtenue par la connexion receveuse est un peu en-de de
0.4 Mbits/s en moyenne sur la priode de collaboration entre les instants
200 et 400. Dautre part, la connexion d2 subit une diminution elle aussi
4.2. Gestion cooprative de la QoS et rpartition de dbit 113

Figure 4.15 Dbit TFRC modifi et liss

infrieure aux 0.4 Mbits/s attendus et la connexion d3 , qui devrait conti-


nuer dobtenir un dbit de 0.8 Mbits par seconde, semble subir une lgre
diminution.
Une explication de ces comportements rside sans doute dans la dyna-
mique du mcanisme TFRC. En effet, si TFRC permet de limiter les va-
riations trop brusques de dbit rsultant de lapplication dun mcanisme
orient fentre, il est en contre-partie sujet des temps de convergence
parfois importants. Lorsque le dbit dune connexion scarte du dbit
auquel elle peut normalement prtendre, il peut scouler un temps re-
lativement long de plusieurs dizaines de secondes avant de retrouver le
dbit attendu. Ce phnomne permet dexpliquer les rsultats obtenus en
se basant sur TFRC.
Les rsultats prsents sur les figures 4.16 et 4.17 illustrent un scnario de
collaboration diffrent.
Dans le chapitre 3, nous avons voqu lintrt dobtenir lensemble des
sommets solutions du problme doptimisation permettant de trouver les
quantits des connexions donneuses. En effet, cela pourrait permettre
dans certains cas dobtenir, partir de ces sommets, un ensemble plus
important de solutions. Dans le scnario prcdent, les sommets solution
du polydre sont d2 = 0.4 ; d3 = 0 et d3 = 0.4 ; d2 = 0. Cependant, on
constate que tous les points de larte du polydre forme par ces deux
points sont galement solution. Ainsi, la paire "quilibre" d2 = 0.2 ; d3 =
0.2 est solution.
La priode de collaboration se situe cette fois-ci entre les instants 100 et
200. On constate, comme dans les rsultats prcdents, une augmentation
significative du dbit de la connexion receveuse c1 de presque 0.4 Mbits/s.
114 Chapitre 4. Mise en uvre et valuation de performance

Les deux connexions receveuses voient chacune leur dbit diminuer de 0.2
Mbits/s pour se rapprocher dun dbit de 0.6 Mbits/s.

Figure 4.16 Dbit TFRC modifi - version 2


Les courbes de la figure 4.17, o les dbits ont t lisss, confirment ces
rsultats.

Figure 4.17 Dbit TFRC modifi et liss - version 2

Le scnario de collaboration prcdent mettant en uvre une solution


4.2. Gestion cooprative de la QoS et rpartition de dbit 115

quilibre a montr des rsultats probants, ce qui tend a montrer une cer-
taine flexibilit dans lapplication du modle doptimisation prsent dans
le chapitre 3. Dans la perspective de lutilisation de priorits, notamment
entre les connexions donneuses, on constate que lapproche peut tre ten-
due en disposant de toutes les solutions du problme doptimisation. On
pourrait alors envisager que les connexions puissent collaborer avec des
poids diffrents, indiquant un choix particulier dans lensemble de solu-
tions.

4.2.4.3 Perspectives : Shaper sur TFRC

Nous avons montr que la modification consistant ajouter o retran-


cher une quantit + ou au dbit calcul selon lquation (4.1) par le
mcanisme TFRC permettait de faire collaborer les connexions Transport.
Cependant, les temps de convergence parfois longs de TFRC peuvent en-
trainer des instabilits et une inefficacit du mcanisme de collaboration.
Pour rpondre ce problme, une approche consistant intgrer le cal-
cul de la collaboration dans lquation de TFRC peut tre envisage. Une
autre approche, plus simple mettre en uvre et que nous avons suivie,
consiste utiliser un Shaper. Il faut pour cela contrler le dbit provenant
de lapplication en lui imposant le dbit que lon souhaite voir attribuer
la connexion pendant la priode de collaboration.
Dans la perspective dune implmentation utilisant un protocole de Trans-
port configurable bas sur une architecture modulaire (tel quETP), on
peut envisager la mise en uvre de cette approche par une composition
de modules telle que la composition dun module Shaper au-dessus dun
module TFRC. Pour cela le mcanisme TFRC utiliser est un TFRC clas-
sique et non un contrle de congestion collaboratif.
De cette faon, on laisse le mcanisme TFRC classique en charge de la
rgulation des dbits lorsque la collaboration des connexions nest pas
ncessaire et on utilise une mise en forme du trafic par le biais dun Sha-
per permettant de limiter le dbit des connexions au dbit requis par la
collaboration.
Les courbes de la figure 4.18 montrent les rsultats issus dune simulation
de la mise en uvre dun Shaper combin TFRC.
Afin de diversifier les scnarios de collaboration, nous nous intressons
ici un scnario o la connexion receveuse demande un incrment de
= 0.2Mbits/s et la priode de collaboration stend entre les instants 100
et 200.
Pour les connexions donneuses d2 et d3 , la rsolution du problme dopti-
misation donne d2 = 0.2 ; d3 = 0.
Jusqu linstant 100, les trois connexions se partagent quitablement la
bande passante avec un dbit oscillant autour de 0.8 Mbits/s. Entre les
instants 100 et 200, qui correspond la priode de collaboration, le dbit
des connexions donneuses est mis en forme. La connexion d2 est limi-
te un dbit de 0.6 Mbits/s et la connexion d3 est limite un dbit
116 Chapitre 4. Mise en uvre et valuation de performance

de 0.8 Mbits/s. On constate alors que le dbit de la connexion receveuse


augmente de 0.2 Mbits/s et atteint 1 Mbits/s. La collaboration est donc
effective. A partir de linstant 200, on stoppe la mise en forme du trafic et
le mcanisme TFRC conduit nouveau une rpartition des dbits autour
de 0.8 Mbits/s.

Figure 4.18 Dbit TFRC + Shaper avec connexions donneuses non contraintes

Conclusion du chapitre

La premire partie de ce chapitre a prsent lvaluation des performances


du composant APA de gestion de ladaptation du systme de gestion
adaptative de la QoS que nous avons labor dans le projet NETQoS. Les
rsultats, qui concernent les mtriques lies au temps de service de lAPA,
ont montr la pertinence des choix dimplmentation de ce composant
pour un nombre acceptable de requtes de service. Dans un contexte dac-
tivits de groupe tel que celui des OIU, le nombre limit de participants
et en consquence le nombre limit de connexions de Transport en jeu,
permettent denvisager une adquation de nos choix ce contexte.
La deuxime partie du chapitre a montr la faisabilit du mcanisme de
contrle de congestion collaboratif. Une premire tude a montr com-
ment, sur des priodes de temps longues, le mcanisme de gestion co-
oprative de la bande passante pouvait tre mis en uvre en soulignant
limportance de la localisation des points de congestion. Le mcanisme
propos a galement t valu sous langle des perturbations quil tait
susceptible de susciter au niveau des connexions ne participant pas au
mcanisme de collaboration. Une deuxime tude a permis dillustrer la
4.2. Gestion cooprative de la QoS et rpartition de dbit 117

mise en uvre du modle doptimisation propos au chapitre 3, propo-


sant une rpartition de la bande passante en fonction des connexions plus
ou moins prioritaires. Les rsultats ont permis de montrer lefficacit de
lapproche, y compris sur des priodes de temps courtes o la stabilit des
dbits nest pas toujours vidente acqurir.
Les perspectives de ce travail sont nombreuses. Si notre tude a permis
de valider lapproche base sur le modle doptimisation que nous avons
propos en montrant sa faisabilit, elle a galement soulev plusieurs in-
terrogations, nous amenant dire que ltude doit tre poursuivie.
Contrle de congestion collaboratif. La premire remarque concerne
lutilisation du mcanisme de contrle de congestion TFRC et la modi-
fication qui lui a t apporte. Nous avons constat des comportements
divergents dans certains scnarios et certaines configurations de rseau.
Une tude plus approfondie des comportements du mcanisme doit
tre mene afin damliorer le mcanisme propos, soit en intgrant
les augmentations et diminutions de dbits requises directement dans
lquation 4.1 de TFRC, soit en combinant un mcanisme de Shaping
un TFRC classique par le biais dun protocole de Transport configurable
tel que ETP par exemple.

Impact de diffrents paramtres. La premire interrogation, mentionne


ci-dessus, nayant pas t clarifie, limpact de plusieurs autres para-
mtres na pas t valu dans nos simulations. Il sagit ainsi de pour-
suivre ltude en valuant linfluence sur la mise en uvre du mca-
nisme :
du nombre de nuds dans le rseau et des diffrents types de topo-
logies
du nombre de connexions donneuses et receveuses impliques dans
la collaboration
du dbit des connexions, ainsi que des valeurs de / appliques
de la capacit des liens et des dlais associs ces liens.
Le mcanisme de collaboration bas sur le contrle de congestion TFRC
pourra ainsi tre modifi, amlior et valid.

Dcision de collaboration. Pour la mme raison, les questions lies


la prise de dcision de la collaboration nont pas pu tre abordes et
doivent tre considres en perspective de ce travail. Parmi les ques-
tions possibles, celles qui nous semblent pertinentes sont par exemple
les suivantes : quel moment dcide-t-on quune collaboration est
ncessaire ? partir de quel seuil de dbit ? pendant combien de temps
ce dbit reste-t-il en dessous du seuil pour quune collaboration soit
envisage ? comment dtecter que lon doit mettre fin la collaboration ?

Dsynchronisation de la dcision. Enfin, lvaluation des consquences


dune application asynchrone des dcisions reste un travail mener.
En dautres termes, il sagit dvaluer limpact sur la rpartition des
ressources dune mise en uvre non synchronise des diminutions et
des augmentations de dbit issues de la dcision de collaboration.
Conclusion

Les travaux que nous avons prsents dans ce mmoire sinscrivent dans
la problmatique gnrale de ladaptabilit des systmes de communica-
tion pour rpondre aux besoins en QoS des applications amenes tre
distribues dans une vison future dun Internet ambiant.
Dans cette optique, lobjectif de notre thse tait daborder le problme de
ladaptation dynamique de protocoles de Transport configurables, pour
rpondre aux besoins en QoS dapplications multimdias distribues dans
un contexte dactivits coopratives de groupe telles que les oprations
dintervention durgence.
Le chapitre 1 a prsent le panorama des solutions de gestion de la QoS
dans lInternet et a positionn nos travaux. Les diffrentes solutions pr-
sentes ont t classes en deux approches : lune base rservation pour
la garantie de QoS, et lautre base adaptation pour loptimisation de la
QoS. Nos travaux sinscrivent dans cette deuxime approche et visent plus
spcifiquement contribuer au dveloppement de protocoles de Transport
auto-configurables. Ladaptation cible touche les mcanismes du proto-
cole quil sagit de pouvoir paramtrer, voire remplacer, dynamiquement.
Le premier problme traiter pour contribuer lauto-adaptation des pro-
tocoles est li au besoin dune architecture de contrle de ladaptation. Le
chapitre 2 a prsent notre proposition darchitecture, dveloppe dans le
cadre du projet europen NETQoS. Les diffrentes fonctionnalits et les
composants de cette architecture permettant de dcider et de faire appli-
quer des actions dadaptation au niveau Transport ont ainsi t prsents
au travers de plusieurs cas dutilisation. Nous avons galement prsent
de faon plus dtaille nos choix de conception pour les composants rele-
vant de nos contributions spcifiques au projet, qui concernent le niveau
Transport.
Le second problme traiter pour contribuer lauto-adaptation des pro-
tocoles concerne les actions dadaptation cibles. Dans le chapitre 3, nous
avons propos une contribution originale pour llaboration dun sys-
tme de gestion cooprative de la QoS. Pour des activits coopratives
de groupe qui induisent potentiellement des priorits entre communica-
tions, un tel systme de gestion de la QoS peut tre intressant pour r-
pondre au mieux aux pnuries de ressources induites par le rseau ou
par son utilisation. Le chapitre 3 traite plus spcifiquement du problme
de la rpartition de la bande passante entre les connexions de Transport.
Notre approche, base modle, nous a conduit poser le problme sous la
forme dun problme de programmation linaire, cest--dire dune fonc-
tion objectif satisfaire sous contraintes. Nous avons par ailleurs discut la
pertinence et lutilisation de diffrents critres. Lintgration de cette solu-

119
120 Conclusion

tion dans larchitecture prsente au chapitre 2 a galement t propose.


Par ailleurs, le problme de la rcupration des informations de supervi-
sion ncessaires la mise en uvre dun systme de gestion cooprative
de la QoS, a t abord.
Enfin, dans le but de montrer la faisabilit des choix darchitecture et du
concept de gestion cooprative de la QoS proposs dans ce mmoire, le
chapitre 4 a prsent une valuation des contributions exposes aux cha-
pitres 2 et 3. La premire partie de ce chapitre a prsent lvaluation des
performances du composant de gestion de ladaptation de niveau Trans-
port (APA) du systme NETQoS. La deuxime partie du chapitre a montr
la faisabilit et la pertinence du mcanisme de contrle de congestion co-
opratif. Les rsultats ont permis de montrer lefficacit de lapproche, y
compris sur des priodes de temps courtes o la stabilit des dbits nest
pas toujours vidente acqurir.

Perspectives

Pour aboutir une gestion cooprative de la QoS Transport dans un


contexte dactivits de groupe de type OIU, les perspectives de nos tra-
vaux concernent tant la partie architecture de contrle de ladaptation,
que la partie modle de dcision et actions dadaptation au niveau des
protocoles. Nous les prsentons ci-aprs en commenant par la partie ar-
chitecture.
La proposition darchitecture faite dans le cadre du projet NETQoS a
t conue indpendamment dun environnement rseau spcifique. Pour
aboutir une architecture oprationnelle dans un contexte dOIU (d-
ployes dans des environnements de rseaux potentiellement mobiles et
ad-hoc en tout ou partie), notre proposition est donc raffiner afin de
prendre en compte les caractristiques et les contraintes spcifiques ce
type denvironnement.
De plus, la mise en uvre dune gestion cooprative de la QoS, suivant
un modle de rpartition de la bande passante tel que celui propos dans
ce mmoire, suscite un besoin en monitoring des routeurs et des besoins
applicatifs, pour lequel nous navons indiqu que des pistes. Le travail est
donc poursuivre en termes darchitecture de monitoring, en tudiant en
particulier loverhead induit en termes de trafic et en le confrontant au
problme de la mise lchelle de la solution retenue vis--vis du nombre
de connexions et du nombre de nuds.
Concernant les aspects lis au modle doptimisation et aux actions opra-
tionnelles pour la dcision ainsi que la mise en uvre de notre proposition
de gestion cooprative de la QoS, plusieurs perspectives souvrent gale-
ment en suite directe de nos travaux.
Vis--vis du modle de dcision pour la rpartition de la bande passante,
un travail immdiat est dtudier la complexit lie la rsolution du pro-
blme pos, en fonction dun nombre de connexions ou de nuds. Cette
tude contribuerait valuer lapplication du modle dans un contexte
dfini.
Conclusion 121

Les perspectives plus long terme attenantes au modle doptimisation


sont les suivantes.
Notre proposition de gestion cooprative de la QoS repose sur une notion
de priorit que nous avons instancie de faon simple, distinguant ainsi
les connexions dites donneuses (moins prioritaires) et les connexions dites
receveuses (plus prioritaires).
Dans un contexte dactivits de groupe plus fortement hirarchises,
considrer en consquence une notion de priorit plus complexe amne-
rait une extension de notre modle. Paralllement, la considration dun
modle de rseau non plus filaire mais sans fil, voire mobile et ad hoc,
ncessiterait galement de revoir le modle de faon consquente. Plus
thorique, une dernire perspective damlioration du modle rside dans
une tude approfondie dun algorithme bas sur le simplexe qui permet-
trait de trouver lensemble de tous les sommets solutions, et lensemble
complet des solutions, de la fonction objectif.
Vis--vis des actions dadaptation, celles que nous avons naturellement
testes reposent sur une utilisation particulire du mcanisme protocolaire
TFRC, directement impliqu dans la rpartition de la bande passante entre
les connexions. Une tude plus approfondie de TFRC pourrait conduire
une meilleure utilisation de TFRC pour aboutir un contrle de conges-
tion coopratif amlior. Dans un contexte de rseaux ad-hoc, cette tude
serait mener sur la base des propositions de modification de TFRC faites
pour ce nouveau contexte.
Paralllement, plusieurs questions demeurent concernant par exemple la
dcision des dates de collaboration, notamment celles lies la dtection
des seuils de dbit qui doivent dclencher le dbut et la fin dune colla-
boration. De mme, limpact sur le partage de la bande passante de lap-
plication dune dcision de collaboration de manire asynchrone doit tre
valu.
Bibliographie

[AKA 04] O. Akan and I. Akyildiz, ATL : an adaptive transport layer


suite for next-generation wireless internet, IEEE Journal on Selected
Areas in Communications, vol. 22, no. 5, 2004, pages 802817, Institute of
Electrical and Electronics Engineers, Inc, 445 Hoes Ln, Piscataway, NJ,
08854-1331, USA,. (Cit pages 14, 15 et 16.)
[AME 94] P. Amer, C. Chassot, T. Connolly, M. Diaz and P. Conrad,
Partial-order transport service for multimedia and other applications,
IEEE/ACM Transactions on Networking (TON), vol. 2, no. 5, 1994, pages
440456, IEEE Press Piscataway, NJ, USA. (Cit pages 2 et 30.)
[BAL 01] H. Balakrishnan and S. Seshan, The Congestion Manager,
RFC 3124 (Proposed Standard), june 2001. (Cit page 32.)
[BAL 04] S. Balasubramaniam and J. Indulska, Vertical handover sup-
porting pervasive computing in future wireless networks, Computer
Communications, vol. 27, no. 8, 2004, pages 708719, Elsevier. (Cit
pages 14 et 16.)
[BHA 98] N. Bhatti, M. Hiltunen, R. Schlichting and W. Chiu,
Coyote : A system for constructing fine-grain configurable communi-
cation services, ACM Transactions on Computer Systems (TOCS), vol. 16,
no. 4, 1998, pages 321366, ACM New York, NY, USA. (Cit page 22.)
[BIR 00] K. Birman, B. Constable, M. Hayden, J. Hickey, C. Kreitz, R.
Van Renesse, O. Rodeh and W. Vogels, The horus and ensemble pro-
jects, proceedings of Proceedings of the DARPA Information Survivability
Conference and Exposition (DISCEX00), 2000. (Cit page 21.)
[BLA 98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W.
Weiss, An Architecture for Differentiated Service, RFC 2475 (Infor-
mational), december 1998, Updated by RFC 3260. (Cit page 11.)
[BRA 97a] R. Braden and L. Zhang, Resource ReSerVation Protocol
(RSVP) Version 1 Message Processing Rules, RFC 2209 (Informatio-
nal), september 1997. (Cit page 10.)
[BRA 97b] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin,
Resource ReSerVation Protocol (RSVP) Version 1 Functional Specifi-
cation, RFC 2205 (Proposed Standard), september 1997, Updated by
RFCs 2750, 3936, 4495. (Cit pages 10 et 11.)
[BRI 01] P. Bridges, W. Chen, M. Hiltunen and R. Schlichting, Sup-
porting coordinated adaptation in networked systems, proceedings of
Hot Topics in Operating Systems, 2001. Proceedings of the Eighth Workshop
on, 2001. (Cit page 17.)

123
124 Bibliographie

[CAL 08] M. Callejo-Rodrguez, J. Enrquez-Gabeiras, W. Bura-


kowski, A. Beben, J. Sliwinski, O. Dugeon, E. Mingozzi, G. Stea, M.
Diaz, L. Baresse and others, EuQoS : end-to-end QoS over hetero-
geneous networks, Proceedings of the K-INGN, , 2008. (Cit page 13.)

[CAS 90] J. Case, M. Fedor, M. Schoffstall and J. Davin, Simple Net-


work Management Protocol (SNMP), RFC 1157 (Historic), mai 1990.
(Cit page 86.)

[CHA 96] C. Chassot, M. Diaz and A. Lozes, From the partial order
concept to partial order multimedia connection, Journal for high speed
networks, vol. 5, no. 2, 1996, pages 181191. (Cit pages 3, 31 et 64.)

[CHE 05] L. Chen and W. Heinzelman, QoS-aware routing based on


bandwidth estimation for mobile ad hoc networks, IEEE Journal on
Selected Areas in Communications, vol. 23, no. 3, 2005, pages 561572,
Institute of Electrical and Electronics Engineers, Inc, 445 Hoes Ln, Pis-
cataway, NJ, 08854-1331, USA,. (Cit page 16.)

[CRA 98] E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, A


Framework for QoS-based Routing in the Internet, RFC 2386 (Infor-
mational), august 1998. (Cit page 7.)

[DAN 55] G. Dantzig, A. Orden and P. Wolfe, The generalized simplex


method for minimizing a linear form under linear inequality restraints,
Pacific Journal of Mathematics 8, , 1955, pages 183-195. (Cit page 77.)

[DAS 04] L. DaSilva, S. Midkiff, J. Park, G. Hadjichristofi, N. Davis,


K. Phanse and T. Lin, Network mobility and protocol interoperability
in ad hoc networks, IEEE Communications Magazine, vol. 42, no. 11,
2004, pages 8896, Institute of Electrical and Electronics Engineers, Inc,
445 Hoes Ln, Piscataway, NJ, 08854-1331, USA,. (Cit page 16.)

[DUR 00] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan and A.


Sastry, The COPS (Common Open Policy Service) Protocol, RFC
2748 (Proposed Standard), january 2000, Updated by RFC 4261. (Cit
page 18.)

[ETS 94] E. ETSI, 003 :" Network Aspects (NA), General aspects of Quality
of Service (QoS) and Network Performance (NP), , 1994. (Cit page 7.)

[EXP 03a] E. Exposito, Specification and implementation of a QoS orien-


ted Transport protocol for multimedia applications, PhD thesis, Ins-
titut National Polytechnique de Toulouse, 2003. (Cit pages 2, 22, 29
et 31.)

[EXP 03b] E. Exposito, P. Senac and M. Diaz, FPTP : the XQoS aware
and fully programmable transport protocol, proceedings of ICON2003.
The 11th IEEE International Conference on Networks, 2003, pages 249254.
(Cit pages 2, 14, 15 et 16.)

[FAI 02] G. Fairhurst and L. Wood, Advice to link designers on link


Automatic Repeat reQuest (ARQ), RFC 3366 (Best Current Practice),
august 2002. (Cit page 27.)
Bibliographie 125

[FAR 06] K. Farkas, O. Wellnitz, M. Dick, X. Gu, M. Busse, W. Effels-


berg, Y. Rebahi, D. Sisalem, D. Grigoras, K. Stefanidis and others,
Real-time service provisioning for mobile and wireless networks,
Computer Communications, vol. 29, no. 5, 2006, pages 540550, Elsevier.
(Cit page 14.)
[FLO 06] S. Floyd, E. Kohler and J. Padhye, Profile for Datagram
Congestion Control Protocol (DCCP) Congestion Control ID 3 : TCP-
Friendly Rate Control (TFRC), RFC 4342 (Proposed Standard), march
2006, Updated by RFC 5348. (Cit page 15.)
[FLO 08] S. Floyd, M. Handley, J. Padhye and J. Widmer, TCP Friendly
Rate Control (TFRC) : Protocol Specification, RFC 5348 (Proposed
Standard), september 2008. (Cit pages 15, 17, 20 et 29.)
[GAR 01] T. Gary, M. Hitunen and R. Schlichting, A configurable and
extensible transport protocol, proceedings of IEEE Infocom, 2001, pages
2226. (Cit page 23.)
[HAR 01] W. Hardy, QoS : measurement and evaluation of telecommunica-
tions quality of service, John Wiley & Sons Inc, 2001. (Cit page 7.)
[HEI 99] J. Heinanen, F. Baker, W. Weiss and J. Wroclawski, Assured
Forwarding PHB Group, RFC 2597 (Proposed Standard), june 1999,
Updated by RFC 3260. (Cit page 12.)
[HEI 03] G. Heinz II, Priorities In Stream Transmission Control Proto-
col (SCTP) Multistreaming, PhD thesis, University of Delaware, 2003.
(Cit page 31.)
[HUT 91] N. Hutchinson and L. Peterson, The x-kernel : An architec-
ture for implementing network protocols, IEEE Transactions on Software
engineering, vol. 17, no. 1, 1991, pages 6476. (Cit page 21.)
[IBM 06] IBM, An architectural blueprint for autonomic computing.,
white paper, , 2006. (Cit pages 3 et 19.)
[ISO94] Quality management and quality assurance Vocabulary, se-
cond edition, 1994. (Cit page 7.)
[ISO00] Quality management principle, 2000. (Cit page 7.)
[ITU 93] E. ITU, 800, ITU-T Recommendation E, vol. 800, 1993, pages
112. (Cit page 7.)
[ITU01] ITU-T G.1010 - End-user multimedia QoS categories, november
2001. (Cit pages 9 et 38.)
[JAC 99] V. Jacobson, K. Nichols and K. Poduri, An Expedited For-
warding PHB, RFC 2598 (Proposed Standard), june 1999, Obsoleted
by RFC 3246. (Cit page 12.)
[KAL 06] A. Kaloxylos, G. Lampropoulos, N. Passas and L. Merakos,
A flexible handover mechanism for seamless service continuity in he-
terogeneous environments, Computer Communications, vol. 29, no. 6,
2006, pages 717729, Elsevier. (Cit pages 14 et 16.)
126 Bibliographie

[KHA 01] I. Khalil and T. Braun, Implementation of a bandwidth bro-


ker for dynamic end-to-end capacity reservation over multiple diffserv
domains, Lecture Notes in Computer Science, , 2001, pages 160174,
Springer. (Cit page 12.)

[KOH 06] E. Kohler, M. Handley and S. Floyd, Datagram Congestion


Control Protocol (DCCP), RFC 4340 (Proposed Standard), march 2006,
Updated by RFCs 5595, 5596. (Cit pages 2 et 20.)

[LAN 04] R. Landry, K. Grace, A. Saidi and M. Bedford, On the design


and management of heterogeneous networks : a predictability-based
perspective, IEEE Communications Magazine, vol. 42, no. 11, 2004, pages
8087, Institute of Electrical and Electronics Engineers, Inc, 445 Hoes Ln,
Piscataway, NJ, 08854-1331, USA,. (Cit page 17.)

[LI 98] T. Li and Y. Rekhter, A Provider Architecture for Differentiated


Services and Traffic Engineering (PASTE), RFC 2430 (Informational),
october 1998. (Cit page 11.)

[LUB 02] M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley and


J. Crowcroft, Forward Error Correction (FEC) Building Block, RFC
3452 (Experimental), december 2002, Obsoleted by RFCs 5052, 5445.
(Cit page 26.)

[MAR 01] I. Marshall and C. Roadknight, Provision of quality of ser-


vice for active services, Computer Networks, vol. 36, no. 1, 2001, pages
7585, Elsevier. (Cit page 14.)

[MIR 01] H. Miranda, A. Pinto and L. Rodrigues, Appia : A flexible


protocol kernel supporting multiple coordinated channels, procee-
dings of INTERNATIONAL CONFERENCE ON DISTRIBUTED COM-
PUTING SYSTEMS, vol. 21, IEEE Computer Society ; 1999, 2001, pages
707710. (Cit page 21.)

[MOC 05] J. Mocito, L. Rosa, N. Almeida, H. Miranda, L. Rodrigues


and A. Lopes, Context Adaptation of the Communication Stack, pro-
ceedings of In ICDCSW 05 : Proceedings of the Third International Work-
shop on Mobile Distributed Computing (MDC) (ICDCSW05). IEEE Compu-
ter Society, 2005. (Cit pages 15 et 16.)

[NIC 98] K. Nichols, S. Blake, F. Baker and D. Black, Definition of the


Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,
RFC 2474 (Proposed Standard), december 1998, Updated by RFCs 3168,
3260. (Cit page 11.)

[NIC 99] K. Nichols, V. Jacobson and L. Zhang, A Two-bit Differentia-


ted Services Architecture for the Internet, RFC 2638 (Informational),
july 1999. (Cit page 12.)

[OTT 07] D. Ott and K. Mayer-Patel, An open architecture for


transport-level protocol coordination in distributed multimedia appli-
cations, ACM Transactions on Multimedia Computing, Communications,
and Applications (TOMCCAP), vol. 3, no. 3, 2007, page 17, ACM. (Cit
page 32.)
Bibliographie 127

[OWE 98] P. Owezarski, M. Diaz and C. Chassot, A time-efficient ar-


chitecture for multimedia applications, IEEE Journal on Selected Areas
in Communications, vol. 16, no. 3, 1998, pages 383396, Citeseer. (Cit
pages 3, 30, 31 et 64.)

[POS 80] J. Postel, User Datagram Protocol, RFC 768 (Standard), au-
gust 1980. (Cit page 20.)

[POS 81] J. Postel, Transmission Control Protocol - DARPA Internet Pro-


gram Protocol SpecificationRFC 793, Network Information Center. SRI
International, Menlo Park. Calif, , 1981. (Cit pages 20 et 25.)

[RAC 08] S. Racaru, Conception et validation dune architecture de signali-


sation pour la garantie de qualit de service dans lInternet multi-domaine,
multi-technologie et multi-service, 2008. (Cit page 13.)

[REC 02] I. Rec, Y. 1541, Network performance objectives for IP-based ser-
vices, , 2002. (Cit pages 9 et 38.)

[RIT 84] D. Ritchie, A stream input-output system, AT&T Bell Labo-


ratories Technical Journal, vol. 63, no. 8, 1984, pages 18971910, Citeseer.
(Cit page 23.)

[SAM 05] N. Samaan and A. Karmouch, An automated policy-based


management framework for differentiated communication systems,
IEEE Journal on Selected Areas in communications, vol. 23, no. 12, 2005,
pages 22362247, Institute of Electrical and Electronics Engineers, Inc,
445 Hoes Ln, Piscataway, NJ, 08854-1331, USA,. (Cit pages 16 et 18.)

[SCH 93] D. Schmidt, D. Box and T. Suda, ADAPTIVE : A Dynamically


Assembled Protocol Transformation, Integration, and eValuation Envi-
ronment, Concurrency : Practice and Experience, , 1993, Citeseer. (Cit
pages 22 et 23.)

[SHA 01] N. Shaha, A. Desai and M. Parashar, Multimedia content


adaptation for QoS management over heterogeneous networks, pro-
ceedings of International Conference on Internet Computing, Citeseer, 2001.
(Cit page 15.)

[SHE 97] S. Shenker, C. Partridge and R. Guerin, Specification of Gua-


ranteed Quality of Service, RFC 2212 (Proposed Standard), september
1997. (Cit pages 10 et 11.)

[SKA 04] A. Skarmeta and G. Perez, Policy-based dynamic provision of


IP services in a secure VPN coalition scenario, IEEE Communications
Magazine, vol. 42, no. 11, 2004, pages 118124. (Cit pages 14 et 16.)

[STE 99] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G.


Waters, A. Westerinen and J. Wheeler, Policy Framework (Draft),
Internet Engineering Task Force, , 1999. (Cit pages 3 et 18.)

[STE 00] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarz-


bauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang and V. Paxson,
128 Bibliographie

Stream Control Transmission Protocol, RFC 2960 (Proposed Stan-


dard), october 2000, Obsoleted by RFC 4960, updated by RFC 3309.
(Cit page 20.)
[STE 04] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen and P. Conrad,
Stream Control Transmission Protocol (SCTP) Partial Reliability Ex-
tension, RFC 3758 (Proposed Standard), mai 2004. (Cit pages 3, 21
et 64.)
[STE 07] R. Stewart, Stream Control Transmission Protocol, RFC 4960
(Proposed Standard), september 2007. (Cit page 15.)
[TER 99] A. Terzis, L. Wang, J. Ogawa and L. Zhang, A two-tier re-
source management model for the internet, GLOBECOM-NEW YORK-,
vol. 3, 1999, pages 17791791, Citeseer. (Cit page 13.)
[VAN 09] N. Van Wambeke, Une approche pour la composition auto-
nome de services de communication orients QoS : application aux
protocoles de transport configurables, PhD thesis, Institut National
des Sciences Appliques - Universit de Toulouse, 2009. (Cit pages 21
et 23.)
[WON 01] G. Wong, M. Hiltunen and R. Schlichting, A configurable
and extensible transport protocol, proceedings of IEEE INFOCOM,
vol. 1, Citeseer, 2001, pages 319328. (Cit pages 15 et 16.)
[WRO 97a] J. Wroclawski, Specification of the Controlled-Load Net-
work Element Service, RFC 2211 (Proposed Standard), september
1997. (Cit pages 10 et 11.)
[WRO 97b] J. Wroclawski, The Use of RSVP with IETF Integrated Ser-
vices, RFC 2210 (Proposed Standard), september 1997. (Cit page 11.)
[WU 00] D. Wu, Y. Hou and Y. Zhang, Transporting real-time video over
the Internet : Challenges and approaches, Proceedings of the IEEE, vol.
88, no. 12, 2000, pages 18551875, Institute of Electrical and Electronics
Engineers. (Cit pages 8, 25 et 29.)
[WU 01] D. Wu, Y. Hou, W. Zhu, Y. Zhang and J. Peha, Streaming video
over the internet : Approaches and directions, IEEE transactions on
circuits and systems for video technology, vol. 11, no. 3, 2001, pages 282
300, Citeseer. (Cit pages 14, 15 et 16.)
[YU 03] F. Yu, Q. Zhang, W. Zhu and Y. Zhang, QoS-adaptive proxy
caching for multimedia streaming over the Internet, IEEE transactions
on circuits and systems for video technology, vol. 13, no. 3, 2003, pages 257
269, Citeseer. (Cit page 14.)
[ZHA 01] Z. Zhang, Z. Duan and Y. Hou, On scalable design of band-
width brokers, IEICE TRANSACTIONS ON COMMUNICATIONS E
SERIES B, vol. 84, no. 8, 2001, pages 20112025, INSTITUTE OF ELEC-
TRONICS, INFORMATION &. (Cit page 13.)
[ZIM 80] H. Zimmermann, OSI reference modelThe ISO model of ar-
chitecture for open systems interconnection, IEEE Transactions on com-
munications, vol. 28, no. 4, 1980, pages 425432. (Cit page 14.)
Bibliographie de lauteur

Revues Internationales avec comit de lecture


[CHA 06a] C. Chassot, K. Guennoun, K. Drira, F. Armando, E. Expo-
sito and A. Lozes, Towards autonomous management of QoS through
model-driven adaptability in communication-centric systems, Interna-
tional Transactions on Systems Science and Applications, vol. 2, no. 3, 2006,
pages 255264.

[GUE 08] K. Guennoun, K. Drira, N. Van Wambeke, C. Chassot, F. Ar-


mando and E. Exposito, A framework of models for QoS-oriented
adaptive deployment of multi-layer communication services in group
cooperative activities, Computer Communications, vol. 31, no. 13, 2008,
pages 30033017, Elsevier.

[VAN 08a] N. Van Wambeke, F. Armando, C. Chassot and E. Expsito,


A model-based approach for self-adaptive Transport protocols, Com-
puter Communications, vol. 31, no. 11, 2008, pages 26992705, Elsevier.

[VAN 09b] N. Van Wambeke, F. Armando, A. Abdelkafi, C. Chassot,


K. Guennoun and K. Drira, Models and Architecture for Autonomic
Network Management, Int. Journal of Business Data Communications and
Networking, vol. 5, no. 2, 2009, pages 3551.

Confrences Internationales avec comit de lec-


ture
[ARM 08] F. Armando, N. Van Wambeke and C. Chassot, Introducing
a collaborative congestion control based on TFRC, proceedings of the
World Congress on Engineering and Computer Science (WCECS), San Fran-
cisco, USA, October 2008, IAENG.

[VAN 08b] N. Van Wambeke, F. Armando, C. Chassot, K. Guennoun,


K. Drira and E. Exposito, Towards the Use of Models for Autonomic
Network Management, IFIP International Conference on Personal Wireless
Communications (PWC2008) - Toulouse, France, September 30, October 2,
2008.

[ARM 07] F. Armando, N. Van Wambeke, C. Chassot, E. Expsito and


K. Drira, A framework for the dynamic configuration of adaptive
transport protocols, Proceedings of the International Conference on Wire-
less Information Networks and Systems (WINSYS 2007), Barcelona (Spain),
28-31 July 2007, pages 275-283.

129
130 Bibliographie de lauteur

[VAN 07] N. Van Wambeke, F. Armando, C. Chassot and E. Expsito,


Architecture and Models for self-adaptability of Transport protocols,
Proceedings of the 21st IEEE International Conference on Advanced Infor-
mation Networking and Applications (AINA-07) Workshops, Niagara Falls,
Canada, May 21-23 2007.

[CHA 06b] C. Chassot, K. Drira, F. Armando, E. Exposito and A.


Lozes, A model-based coordinated adaptability framework for QoS
management in cooperative mobile and wireless applications, Procee-
dings of the 9th ACM international symposium on Modeling analysis and
Simulation of Wireless and Mobile System, (ACM/IEEE MSWiM ?06), Tor-
remolinos, Spain, October 2-6, 2006.

Rapports Projet europen IST NETQoS


[CHA 07a] C. Chassot, E. Exposito, N. Van Wambeke, F. Armando, I.
Bouassida, K. Drira, C. Brandauer, F. Strohmeier, P. Dorfinger,
P. A. A. Gutierrez, A. Flizikowski, K. Samp, I. Miloucheva, S. Aval-
lone, L. Vollero, S. P. Romano, M. Michalak, M. Roth and S. Rao,
D2.1 - QoS solution Analysis and User/application requirements and
business scenarios, Tech. report, 2007, IST FP6 - NetQoS.

[CHA 07b] C. Chassot, E. Exposito, N. Van Wambeke, F. Armando, C.


Brandauer, T. Fichtel, S. Kavthasi, S. Rao, I. Miloucheva, D. Wag-
ner, A. Flizikowski, R. Marcinczak, S. Avallone, S. P. Romano and
A. Dainotti, D2.3 - Policy specification, Tech. report, 2007, IST FP6 -
NetQoS.

[CHA 07c] C. Chassot, E. Exposito, N. Van Wambeke, F. Armando,


C. Brandauer, T. Fichtel, S. Kavthasi, S. Rao, I. Miloucheva, D.
Wagner, A. Flizikowski, R. Marcinczak, S. Avallone, S. P. Romano
and A. Dainotti, D2.4 - Specification of policy-oriented measurement,
learning, and context identification, Tech. report, 2007, IST FP6 - Net-
QoS.

[CHA 07d] C. Chassot, E. Exposito, N. Van Wambeke, F. Armando, C.


Brandauer, J. Neuhaus, M. Roth, S. Rao, I. Miloucheva, A. Flizi-
kowski, R. Marcinczak, P. A. A. Gutierrez, S. Avallone and S. P.
Romano, D2.2 - Design of the NetQoS policy architecture, Tech. re-
port, 2007, IST FP6 - NetQoS.

[CHA 08] C. Chassot, E. Exposito, N. Van Wambeke, F. Armando, C.


Brandauer, S. Khavatsi, S. Rao, S. Avallone, S. Romano, A. Pescape,
A. Botta, A. Dainotti, W. D. Donato, L. Vollero and P. A. Gutier-
rez, D2.6 : Implementation of policy-oriented measurement, learning,
and context identification, Tech. report, 2008, IST FP6 - NetQoS.

[FLI 08] A. Flizikowski, R. Marcinczac, I. Miloucheva, S. Khavatsi,


S. Rao, S. Avallone, S. Romano, N. Van Wambeke, F. Armando, E.
Exposito and C. Chassot, D2.5 : Policy implementation, Tech. report,
2008, IST FP6 - NetQoS.
Bibliographie de lauteur 131

[GUT 07] P. A. A. Gutierrez, C. Chassot, E. Exposito, F. Armando, N.


Armando, N. Van Wambeke, C. Brandauer, S. Khavtasi, S. Rao, D.
Wagner and A. Flizikowski, D3.1 - Specification of policy-oriented
measurement, learning, and context identification, Tech. report, 2007,
IST FP6 - NetQoS.

[GUT 08a] P. A. Gutierrez, F. Trivunac, I. Miloucheva, D. Wagner, C.


Niephaus, C. Chassot, N. Van Wambeke, C. Brandauer, A. Flizi-
kowski, F. Armando, S. Rao and S. P. Romano, D3.4 : Performance
Assessment, Tech. report, 2008, IST FP6 - NetQoS.

[GUT 08b] P. A. A. Gutierrez, S. Rao, S. Khavtasi, C. Brandauer, A.


Flizikowski, C. Chassot, N. Van Wambeke, F. Armando, I. Milou-
cheva, D. Wagner and S. P. Romano, D3.2 : System integration (first
prototype) and test report, Tech. report, 2008, IST FP6 - NetQoS.

[MIL 08a] I. Miloucheva, D. Wagner, C. Niephaus, C. Chassot, N. Van


Wambeke, P. A. Gutierrez, F. Trivunac, C. Brandauer, A. Flizi-
kowski, S. Khavtasi, F. Armando, S. Rao and S. P. Romano, D3.3 :
Trials execution, Tech. report, 2008, IST FP6 - NetQoS.

[MIL 08b] I. Miloucheva, D. Wagner, C. Niephaus, C. Chassot, N.


Van Wambeke, P. A. Gutierrez, F. Trivunac, C. Brandauer, A. Fli-
zikowski, S. Khavtasi, F. Armando, S. Rao and S. P. Romano, D3.5 :
Validation and Exploitation report, Tech. report, 2008, IST FP6 - Net-
QoS.
Glossaire

AF Assured Forwarding
APA Automated Policy Adaptor
API Application Programming Interface (interface de programmation)
APM Actor Preference Manager
ARQ Automatic Repeat Request
AS Autonomous System
CL Controlled Load
CM Context Manager
COPS Common Open Policy Service
DCCP Datagram Congestion Control Protocol
EF Expedited Forwarding
ETP Enhanced Transport Protocol
FEC Forward Error Correction
FIFO First In, First Out
GUI Graphical User Interface
GS Guaranted Service
IETF Internet Engineering Task Force
ISO International Organization for Standardization
ITU International Telecommunication Union
JVM JavaVirtual Machine
MAC Media Access Control
MoMe Monitoring and Measurement
OIU Oprations dIntervention dUrgence
OSI Open Systems Interconnection
PAM Policy Adaptation Manager
PBNM Policy Based Network Management
PDA Personal Digital Assistant
PDP Policy Decision Point
PDM Policy Decision Manager
PDU Protocol Data Unit
PEP Policy Enforcement Point
PEM Policy Enforcement Manager
PHB Per Hop Behavior
PIB Policy Information Base
POC Partial Order Connection
POLD Policy Description
RSVP Resource ReSerVation Protocol
RTP Real time Transport Protocol

133
QoS Quality of Service (Qualit de Service)
SCTP Stream Control Transmission Protocol
SLA Service Level Agreement
SLS Service Level Specification
TFRC TCP Friendly Rate Control
TCP Transmission Control Protocol
TOS Type of Services
UDP User Datagram Protocol
UML Unified Modeling Language
XML eXtensible Markup Language

134
AUTHOR : Franois ARMANDO

TITLE : Cooperative QoS for Transport protocols adaptability within


group activities

SUPERVISORS : Christophe CHASSOT, Khalil DRIRA

Abstract : The work presented in this thesis fits into the overall theme of
adaptability of communication systems for QoS. The proposed contribu-
tion focuses on the dynamic adaptation of configurable transport proto-
cols to meet the QoS requirements of distributed multimedia applications
in the context of cooperative activities such as emergency operations. The
first part was conducted in the framework of the NetQoS European pro-
ject and concerns the proposal of a conceptual architecture for implemen-
ting adaptation at the Transport layer. Within a policy-based approach,
our contribution has addressed the development of the architecture of
the main component. This component is in charge of designing, adapting
and enforcing operational policies to the entities responsible for direct
QoS management, typically at Transport level. The second part focuses
on the decision problem and proposes a novel approach for collaborative
management of transport protocols for supporting adaptive QoS in co-
operative group activities. The approach explored is to focus on transport
connections with the highest priority to the detriment of lower priority
connections, within the allowed sending rate. We consider the problem of
allocating bandwidth between these connections. After defining the pro-
blem and the data required for its resolution, we formulate it as a linear
programming problem solved by the simplex method. Two minimization
criteria are considered and discussed. Finally, measures of performance
achieved in simulation highlight the benefits and limitations of proposed
solutions.

Keywords : Quality of Service, Transport protocol, Adaptability, Group


activities

135
AUTEUR : Franois ARMANDO

TITRE : QoS cooprative pour ladaptabilit des protocoles de Transport


dans le contexte des activits de groupe

DIRECTEURS DE THESE : Christophe CHASSOT, Khalil DRIRA

LIEU ET DATE DE SOUTENANCE : LAAS-CNRS, Toulouse, le 17 f-


vrier 2010

Rsum : Les travaux prsents dans cette thse sinscrivent dans le


thme gnral de ladaptabilit des systmes de communication pour la
QoS. La contribution propose porte sur ladaptation dynamique de proto-
coles de Transport, pour rpondre aux besoins en QoS dapplications mul-
timdia distribues dans un contexte dactivits coopratives de groupe de
type oprations dintervention durgence. La premire partie a t ralise
dans le cadre du projet europen projet IST NETQoS et porte sur une pro-
position darchitecture conceptuelle pour la mise en uvre de ladaptation
au niveau Transport. Suivant une approche base politique, les contribu-
tions exposes portent sur llaboration de larchitecture du composant
central du systme, charg de concevoir, dadapter et de faire appliquer
des politiques oprationnelles aux entits en charge de la gestion directe
de la QoS. La deuxime partie porte sur le problme de la dcision et
propose une approche originale de gestion collaborative des protocoles
de Transport pour la QoS dans les activits coopratives de groupe. Lap-
proche explore vise privilgier les connexions de Transport les plus
prioritaires au dtriment des connexions les moins prioritaires. Nous nous
intressons au problme de la rpartition de la bande passante entre ces
connexions. Aprs avoir dfini le problme et les donnes ncessaires
sa rsolution, nous le formulons sous la forme dun problme de pro-
grammation linaire rsolu grce la mthode du simplexe. Deux critres
de minimisation sont envisags et discuts. Enfin, des mesures de perfor-
mance ralises en simulation permettent de mettre en vidence le bien
fond et les limites des solutions proposes.

Mots-cls : Qualit de Service, Protocole de Transport, Adaptabilit, Ac-


tivits coopratives

Discipline Administrative : Informatique et Tlcommunications

Intitul et adresse du Laboratoire : Laboratoire dAnalyse et dArchitec-


tures des Systmes - 7 avenue du colonel roche - 31077 Toulouse

136