Fabien Michaut fabien.michaut@cran.uhp-nancy.fr

Adaptation des applications distribuées à la Qualité de Service fournie par le réseau de communication

Fabien Michautfabien.michaut@cran.uhp-nancy.fr

Centre de Recherche en Automatique de NancyCRAN - CNRS UMR 7039

Université Henri Poincaré - Nancy I

2

Exemple de télé-opération

Dispositiféchographique

Poste decommande

Echographie à distance

Réseau

Trafics "complexes": contrôle, vidéo Trafics contraints Fonctionnement de l'application dépendant de la Qualité de

Service (QdS) fournie par le réseau de communication Prise en compte de la QdS du réseau indispensable

3

Approches possibles Réservation de ressources

[IntServ95], [Nahrstedt95], etc. Garantie stricte de QdS Performances optimales de l'application

Maîtrise des ressources pas totale ou impossible

Réseaux hétérogènes (Ex: Internet) Adaptation des applications aux ressources

disponibles "Multimedia applications should be adaptive" [Diot95]

4

Générique?

Spécification QdS?

SpécificationQdS? Stabilité?

Mécanismed'adaptation

Adapter les applications à la QdS disponible?

Mesurer la QdS

Mécanismed'adaptation

Interactions?

Besoin d'un cadre pour l'adaptation:Architecture de QdS

Utilisateur

5

Principes Transparence et séparation [Campbell96]

Mécanismes de gestion de QdS transparents pour l'application

Nombre limité de fonctionnalités "QdS" à implanter dans l'application

Complexité de la gestion de la QdS déléguée à l'architecture

Séparation des tâches de gestion de la QdS et de traitement des flux applicatifs

Ex. d'une application vidéo: Signalisation <-> Flux vidéo

Facilite le travail du développeur d'applications Permet une vision / gestion globale de toutes

les applications

6

Spécification/Traduction de QdS [Cheong99] Spécification de la QdS

Utilisateur, application, système d'exploitation, système de communication

Exemple d'une application vidéoUtilisateur Qualité vidéo subjective

Application Codec vidéo, taille de l'image, etc.

Système decommunication Bande passante, etc.

Systèmed'exploitation Mémoire, etc.

Traduction (translation) de la QdS Conversion de la spécification de la QdS

7

Mécanismes d'adaptation existants Adaptation du débit de la source

Flux audio/vidéo Taux de compression / choix du codec (Ex: [Fry99])

Dimensionnement dynamique de mémoires-tampon

Compensation de gigue Flux audio (Ex: [Benaissa02])

Techniques plus génériques Librairies de composants adaptables [Chang99][Ott98]

Implique de prévoir tous les composants possibles Modèle Prayer [Bharghavan97]

Exécution d'un code différent selon la QdS L'application spécifie comment réagir lorsque la QdS varie Un superviseur extérieur pilote l'adaptation Transparence/Séparation

8

Modèles existantsXRM

[Lazar94]QoS-A

[Campbell98]

Omega[Nahrstedt9

6]Heidelberg [Vogt98]

Prayer[Bharghavan97

]Adaptation du débit

Compensation

de gigue

Cadre architectur

al

Spécification QdS Traduction QdS Métrologie

Préférences Utilisateur

Adaptation des

applications

Générique Transparent StabilitéMulti-application

Réservation de ressources

Oui Incomplet Non

9

ProblématiqueAdapter les applications en ligne à la QdS mesurée

Métrologiede la QdS

PréférencesUtilisateur

GénériqueSpécification QdS

StabilitéSpécificatio

nQdS

Traduction QdSTransparent

Architecture de QdS

Multi-application

Mécanismed'adaptation

10

Suite de l'exposé: "QdS-Adapt": Une architecture pour l'adaptation

en ligne des applications Mécanisme d'adaptation des applications Service de métrologie de la QdS Architecture "QdS-Adapt"

Expérimentations Télé-pilotage d'un robot mobile Télé-asservissement en position d'un robot mobile

Conclusions & Perspectives

"QdS–Adapt"Une architecture pour l'adaptation en ligne des applications

1. Mécanisme d'adaptation des applications

2. Service de métrologie de la QdS

3. Architecture "QdS-Adapt"

12

Métrologiede la QdS

GénériqueSpécification QdS

Stabilité

SpécificationQdS

Transparent

Architecture de QdS

Multi-application

Mécanismed'adaptationTraduction QdS

PréférencesUtilisateur

13

Mécanisme d'adaptation en ligne Basé sur des concepts issus du modèle Prayer

[Bharghavan97]

Classes de QdS "Niveaux" de QdS

Séquences d'exécution Associées aux classes de QdS Exécution d'un code différent selon la classe de QdS

disponible

ExempleClasse de QdS 1Classe de QdS 2Classe de QdS 3

+

-

14

Mécanisme d'adaptation: exemple

Choix de la séquence

15

Mécanisme d'adaptation

S e q 1

C la s s e

E ta t In itia l

E x e c u te r se q 1

[x = A ]

T e rm in er s eq 1

F in s e q 1

E ta t F in a l

S eq 2 S e q 3F in s e q 2 F in s e q 3

E x e c u te r se q 2

[x = B ]

E x e c u ter s e q 3

[x = C ]

T e rm in e r s e q 2 T e rm in e r s e q3

Je to n

x

x

x

J e to n

J e to n

x

x

x J e to n

x

x Je to n

J e to n J e to n

Je to n J e to n

x

x

x

x

16

Adaptation en ligne: exemple

t

QdS

17

Actions d'adaptation

Actions "Bas" Initiées lorsque la classe de QdS courante plus disponible BLOCK, BEST_EFFORT, ROLLBACK, ABORT, SWITCH()

Actions "Haut" Initiées lorsque une (des) classe(s) de QdS supérieure(s)

disponible(s) BEST_EFFORT, ROLLBACK, SWITCH()

Un couple (Action Haut, Action Bas) associé à chaque séquence Application informée de l'initiation nécessaire d'une action

d'adaptation

t

QdS

18

Blocs d'adaptation

19

PréférencesUtilisateurs

GénériqueSpécification QdS

Stabilité

SpécificationQdS

Transparent

Architecture de QdS

Multi-application

Mécanismed'adaptationTraduction QdS

Métrologiede la QdS

20

Métrologie de la QdS réseau Mesurer la QdS telle qu'elle est perçue par l'application

Mettre en œuvre une politique de métrologie

Fonctionnalités attendues

Paramètres différentsPlusieurs mesures simultanées

Mesures bidirectionnellesParamétrable

21

Système A

Métrologie de la QdS réseau

Mesurer la QdS telle qu'elle est ressentie par

l'application

Mesures actives:Effectuées en envoyant des

paquets-sonde

Réseau Système B

22

Paramètres retenus et outils de mesures

Outils de mesure

Capacité (lien) Pathchar [Jacobson97], Bing [Beyssac95], Clink [Downey99], Pchar [Mah99], Nettimer [Lai01]

Bande passante disponible (lien/chemin)

Cprobe [Carter96], Pipechar [Jin01], Pathload [Jain02],Spruce [Strauss03], Topp [Melander03]

Bande passante minimale (chemin)

Bprobe [Carter96], Pathrate [Dovrolis01],Nettimer [Lai01], Sprobe [Saroiu01]

Délai unidirectionnel -

Délai aller-retour Ping [BSD4.3]

Variation de délai Iperf [Tirumala03]

Pertes de paquets Ping [BSD4.3], Sting [Savage99], Iperf [Tirumala03]

Route Traceroute [Jacobson89]

23

Analyse

Outils inutilisables pour mettre en œuvre une politique de métrologie

FonctionnalitésParamètres différents NonPlusieurs mesures simultanées NonMesures bidirectionnelles NonParamétrable Non

24

Service de métrologie Cadre générique pour l'implantation de

techniques de mesure Dont les techniques des outils précédents

Mesures actives Réalisées par des couples d'émetteur-récepteur de

paquets-sonde: Capteurs Structure modulaire

Ajout de couples de capteurs

25

Service de métrologie: principe

Service deMétrologie

Application

Capteur

Gère la politique de métrologie:

paramètres à mesurer,période de mesure(caractéristiques de

capteurs)

Système A Système B

Coordinateur

Service deMétrologie

Coordinateur

Canal de contrôle

Agent deSurveillance

Application

Capteur Capteur

Capteur

26

Modélisation UML - Diagramme de Classes

Service deMétrologie

Capteur

Capteur

Système A

Coordinateur

Agent deSurveillance

Application

CapteurActif CapteurPassif

+démarrer()+arrêter()+évaluerTraficMesure()

-tailleSondes

CapteurActifDélaiVdPertesClient

+démarrer()+arrêter()+mesurerDélai()+mesurerVariationDélai()+mesurerPertes()+envoyerMesures()

-délai-variationDélai-pertes-timeout-périodeMesure

CapteurActifDélaiVdPertesServeur

+démarrer()+arrêter()+mesurerRtt()+envoyerMesures()+évaluerTraficMesure()

-périodeSondes-tailleSondes-périodeMesure

CapteurActifRttClient

+démarrer()+arrêter()

CapteurActifRttServeur

-périodeSondes

CapteurActifDélaiVdPertes CapteurActifRtt

+démarrerSurveillance()+validerCréationCapteurs()+recevoirMesures()

-idAgent-périodeMesure

AgentDeSurveillance

+créerCoupleCapteurs()+créerCapteur()+démarrerCoupleCapteurs()+démarrerCapteur()+aiguillerMessage()

Coordinateur

+connecterSystèmeDistant()+envoyerMessage()+recevoirMessage()

CanalDeContrôle

+obtenirAdresseCapteur()+obtenirCanalCapteur()+obtenirAdresseCapteurDistant()+obtenirCanalCapteurDistant()

-idCapteur-idAgent-protocoleTransport-idCapteurDistant

Capteur

-numéro

Canal

-typeCapteur-idAgent-adresseSystèmeLocal-adresseSystèmeDistant-numéroCanalLocal-numéroCanalDistant-protocoleTransport

DescripteurCapteur

1*

1

*

11

*1

1

*

-mesureParamètre1-mesureParamètre2-...

RésultatsDeMesure

1

1

1

*

27

Modélisation UML – Diagramme de Séquence

idCapteur

numéroCanal

AgentDeSurvAppli:AgentDeSurveillance CoordSiteA:Coordinateur

créerCoupleCapteurs

CanalSiteA:Canalcréer

CoordSiteB:Coordinateur

créerCapteur

CanalSiteB:Canalcréer

CapteurDVdPServeur:CapteurActifDélaiVdPertesServeur

créer

idCapteur

créer

idCapteur

validerCréationCapteurs

démarrerCoupleCapteurs

démarrerCapteur démarrer

étatétat

démarrer

état

CapteurDVdPClient:CapteurActifDélaiVdPertesClient

28

Fonctionnalités du service de métrologie

Fonctionnalités

Paramètres différents

Plusieurs mesures simultanées

Mesures bidirectionnelles

Paramétrable

29

Implantation: QoSMet

One-way delay (RFC2679)Type-P-One-way-Delay Type-P-One-way-Delay-Poisson-Stream Type-P-One-way-Delay-Percentile Type-P-One-way-Delay-Median Type-P-One-way-Delay-Minimum

One-way delay variation (RFC3393)Type-P-One-way-ipdv Type-P-One-way-ipdv-Poisson-Stream Type-P-One-way-ipdv-jitter Type-P-One-way-peak-to-peak-ipdv

Packet loss (RFC2680)Type-P-One-way-Packet-Loss Type-P-One-way-Packet-Loss-Poisson-Stream Type-P-One-way-Packet-Loss-Average Type-P-One-way-Packet-Loss

Packet loss pattern sample metrics (RFC3357) Type-P-One-way-Loss-Distance-Stream Type-P-One-way-Loss-Period-Stream Type-P-One-way-Loss-Noticeable-Rate

Packet reordering (draft)Type-P-Reordered-Ratio-Stream

En cours d'implantationBande passante disponible selon l'algorithme "Spruce" [Strauss03]

Paramètres mesurés selon les recommandations de l'IETF(métriques conformes aux

RFCs)

Compatible One-Way Active Measurement Protocol [IETF]

30

Métrologiede la QdS

PréférencesUtilisateurs

GénériqueSpécification QdS

Stabilité

SpécificationQdS

Transparent

Architecture de QdS

Multi-application

Mécanismed'adaptationTraduction QdS

31

Architecture "QdS-Adapt"

Gestion

Application

Ressources

Processeur Mémoire Réseaux

32

Modélisation UML - Diagramme de Classes

+exporterClassesQos()

-périodeBloc-périodeAdaptation

Application

+enregistrerApplication()+déterminerNouvelleClasseQos()+adapterApplication()

Superviseur

1

*

contrôle

+démarrerSurveillance()+validerCréationCapteurs()+recevoirMesures()

-idAgent-périodeMesure

AgentDeSurveillance

1

*

utilise

1

1

correspond à

+exécuterSéquence()+activerActionHaut()+activerActionBas()

-positionCourante

CAP

ClasseQosApplication

1

1

-paramètre1Inf-paramètre1Sup-paramètre2Inf-paramètre2Sup-...

ClasseQosMétrique

1

1

correspond à

+afficherClassesQos()+ordonnerClassesQos()+démarrerApplication()

-préférencesUtilisateur

InterfaceUtilisateur

1

1+enregistrerApplication()+ordonnerApplications()

-préférencesUtilisateurInterApplications

InterfaceUtilisateurInterApplications

1..* 1

représente

+faireTranslation()

Translation

-prioritésApplications

Ordonnanceur

+contrôlerTrafic()

ContrôleurDeTrafic

+corrigerTrafic()

GestionnaireDeFlux

+exporterCAP()-numéro

BlocAdaptation11..*

1

1..*

1

1

interagit avec

1

1

1

1

utilise

11 utilise

1* crée

+mettreAJour()

-classeCourante-classesPrécédentes

Historique

1

1

utilise

*

1

utilise

1

1

33

-Saisie des préférences de l'utilisateur

:InterfaceUtilisateur

:InterfaceUtilisateurInterApplications

Paquetage supérieur::Utilisateur

2: ordonnerClassesQos()

3: démarrerApplication()

1: ordonnerApplications()

:Superviseur :Application

1: enregistrerApplication()2: exporterClassesQos()

:Translation

3: faireTranslation()

:ClasseQosMetriques

3.1: *[i:=1..n]:création()

:AgentDeSurveillance4: création()

5: démarrerSurveillance()

-Enregistrement de l'application auprès du superviseur et exportation des classes de QdS "application"

-Traduction des classes de QdS en classes "métriques"-Création d'un agent de surveillance

-Démarrage de la métrologieDéterminer Nouvelle Classe QoS

[nouvelleClasse := classeCourante]

[sinon]

Démarrer séquence d'exécution suivante

Mettre à jour historique

[bloc en cours d'exécution] [fin d'exécution du bloc courant]

Activer action d'adaptation Haut Activer action d'adaptation Bas

[nouvelle classe < classe courante][nouvelle classe > classe courante]

Pendant l'exécution de l'application-Détermination périodique de la classe de QdS la plus adaptée

-Choix de la séquence d'exécution associée / Activation des actions d'adaptation

:Application

:InterfaceUtilisateur

2: création()

3: afficherClassesQos()

:InterfaceUtilisateurInterApplications1: enregistrerApplication()

-Enregistrement de l'application auprès de l'interface inter-applications

-Création de l'interface utilisateur propre

Fonctionnement

34

Calcul de la classe de QdS la plus adaptée

Principe1. Parmi toutes les classes du bloc en cours, déterminer les classes disponibles selon la QdS courante2. Trier l'ensemble obtenu selon l'ordre indiqué par l'utilisateurSoit A l'ensemble des couples (classes de QdS de l'application, préférence de l'utilisateur):

Soit B l'ensemble des classes de QdS du bloc,

Soit D l'ensemble des classes de QdS de l'application disponibles en fonction de la QdS courante,

L'ensemble des classes de QdS disponibles pour le bloc est

La classe de QdS la plus adaptée est

à ni;npppaA iiii 1,1 , avec ,

AB

AD

nmmj, qeDBE jj , à 1 avec

k...mkjj qqe1

min que tel

35

Métrologiede la QdS

PréférencesUtilisateurs

GénériqueSpécification QdS

Stabilité

SpécificationQdS

Transparent

Architecture QdS-Adapt

Multi-application

Mécanismed'adaptation

Traduction QdS

Expérimentations

Télé-pilotage d'un robot mobileTélé-asservissement en position d'un robot

mobile

37

Plate-forme d'expérimentation

Ordinateur embarqué

Système mobile

Carte réseau sans-fil802.11b

Robot et caméra embarquée

Point d’accès802.11b

Poste decommande

Serveur vidéo http

EmulateurInternet

[Lecuire01]

Délai, pertes

38

Application de télé-pilotage Application démonstrative Suivre le trajet de A à E

39

Stratégie d'adaptation / Classes de QdS Degré d’autonomie du robot variable selon l’importance

des perturbations [Lin96] Modes de pilotage

Mode "joystick" Maîtrise complète du robot par l'opérateur (pilotage interactif)

Mode "rail" Déplacement le long d'un rail virtuel Maîtrise des degrés de liberté du robot partagée entre le robot

et l’opérateur Mode "point à point"

Maîtrise de la trajectoire par le robot (interactivité quasi-nulle)

Interactivitéopérateur-robot+ -

Délaialler-retour (s)

0,100 0,25 1,00

40

Blocs – Séquences – Actions d'adaptationA

B

C

D

E

Aller de A à B(- / SW)

Aller de A à B(B_E / SW)

Aller de A à B(B_E / BL)

Aller de D à E(- / SW)

Aller de D à E(B_E / SW)

Aller de D à E(B_E / BL)

Aller de C à D(- / SW)

Aller de C à D(B_E / BL)

Aller de B à C(- / SW)

Aller de B à C(B_E / BL)

Traj

et

41

Exemple: Bloc B-C

42

Application de télé-asservissement Asservir la position du robot Commande en vitesse

RobotCorrecteurpositionconsigne vitesse

Réseau

Hypothèses Délais identiques à l'aller et au retour Pas de perte de paquets Correcteur proportionnel

2AR

RADDD

43

Boucle de commande Identification du robot

CONTSID [Garnier02] Fonction de transfert en boucle fermée

sD

sD

AR

AR

ekssseksFTBF

3

3

10.7023

210.70

..6117,165611,160450,4..6117,16)(

F(s)k e-(D /2)sYref Y+

-

e-(D /2)s

Correcteurproportionnel

Délai

Fonction de transfertdu robot

AR

AR

ssseksF

s

5611,160450,4..6117,16)( 23

10.70 3

44

Etude en simulation: Impact du réseau Introduction de délai dans la boucle Provoque des dépassements

0 5 10 150

0.2

0.4

0.6

0.8

1

1.2

temps (s)

posi

tion

(mm

)

rtt=0srtt=0.2srtt=0.4s

Simulation Matlab

45

Comment supprimer le dépassement? Calcul d'un gain pour délaiAR max tel

que dépassement nul

Pas satisfaisant Système inutilement lent lorsque le

retard est très inférieur au retard max

Gain (k) 0,9 0,7 0,5 0,3DélaiAR max (s) 0,1 0,3 0,5 1,1tm (s) 1,38 2,37 3,59 6,53

0 5 10 15 200

0.2

0.4

0.6

0.8

1

1.2

1.4

temps (s)

posi

tion

(mm

)

k=0.3 - rtt=0.3k=0.9 - rtt=0.3

Simulation Matlab

46

Stratégie d'adaptation / Classes de QdS Choix du gain du correcteur en fonction du

délaiAR Dépassement au détriment de la rapidité du système

Classe de QdS

Gain (k) 0,9 0,7 0,5 0,3

DélaiAR max (s) 0,1 0,3 0,5 1,1

47

Bloc – Séquences – Actions d'adaptation

Réguler(- / SW)

Gain=0,9

Réguler(B_E / SW)Gain=0,7

Réguler(B_E / SW)Gain=0,5

Réguler(B_E / BL)Gain=0,3

Périodes Choisies en fonction de la dynamique du système Période du bloc: 2s Période du calcul de la classe de QdS la plus adaptée: 0,5s

48

Modélisation

49

Résultats Expérimentaux

Mesure dudélai aller-retour

(secondes)

Gain

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

1.10

1.20

1.30

1.40

1.50

1.60

0 10 20 30 40 50 60 70 80 90 100

0,300,50

1,10

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 10 20 30 40 50 60 70 80 90 1000

0,3

0,5

0,7

temps (s)

délai A-R(s)

k

50

Résultats Expérimentaux (2)

Consigne / Réponse(mm)

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

1.10

1.20

1.30

1.40

1.50

1.60

0 10 20 30 40 50 60 70 80 90 100

0,300,50

1,10

temps (s)

-100

0

100

200

300

400

500

600

700

0 10 20 30 40 50 60 70 80 90 100

consigneréponse

0100200

400

600

position (mm)

Mesure dudélai aller-retour

(secondes)

délai A-R(s)

51

Conclusions Adaptation en cours d'exécution de

l'application en fonction de la QdS mesurée possible

Contributions Architecture de QdS pour l'adaptation Service de métrologie de la QdS Plate-forme d'expérimentation opérationnelle pour

l'accueil et le test de Nouvelles techniques de métrologie Algorithmes de commande évolués pour les systèmes à

retard (Equipe Projet Multi-Laboratoires "Retards de Transmission en Télé-opération", CRAN-LAIL-LIRMM)

52

Conclusions

XRM[Lazar94]

QoS-A[Campbell9

8]

Omega[Nahrstedt9

6]Heidelberg [Vogt98]

Prayer[Bharghavan97

]

QdS-Adapt

[Michaut03]

Cadre architectur

al

Spécification QdS Traduction QdS

Métrologie Préférences Utilisateur

Adaptation des

applications

Générique Transparent Stabilité Multi-application

Réservation de ressources intégrable

Oui Incomplet Non

53

ConclusionsRéservation de

ressourcesAdaptation de l'application

+- Garanties strictes de

QdS

- Performances optimales de l'application

- Fonctionnement correct de l'application même lorsque la maîtrise des

ressources incomplète ou impossible

- Orienter les dégradations de la QdS

-

- Non utilisable pour les réseaux hétérogènes

(Internet)

- Réservation impossible: Mauvais fonctionnement (voire fonctionnement

impossible) de l'application

- Performances inférieures de l'application

- Tolérance aux dégradations limitée (Ex:

Action ABORT)

54

Perspectives Classification des applications

Modèles de spécification de la QdS Fonctions de traduction de la QdS Politiques de métrologie adaptées

Paramètres pertinents, période, etc. Métrologie

Impact du flux de mesure sur le réseau (finesse des capteurs)

Quantifier les incertitudes de mesures Prédiction des mesures

Stabilité Priorités inter-applications