Support de QoS de bout en bout

Le premier critère d’évaluation des solutions proposées est le support de la QoS de bout en bout. C’est-à-dire l’aptitude de ces propositions à assurer la conformité du comportement des flux usagers suivant le contrat souscrit. Mais que recouvre le bout en bout (§3.1.1)? Et dans les propositions existantes, quels éléments impactant la QoS de bout en bout ont été pris en compte (§3.1.2)?

3.1.1 Quel bout en bout ?

Dans les propositions que nous avons présentées, deux « bout en bout » sont considérés. Il y a tout d’abord le bout en bout qui couvre le réseau d’acheminement (§2.1), champs d’action de l’ingénierie de trafic (§2.1). La QoS du réseau d’acheminement est impactée par la mise en relations des éléments de service (applications) que l’on peut offrir aux utilisateurs. Ces éléments de service forment le deuxième niveau de bout en bout considéré par les propositions existantes (§2.2). Mais est ce que ces deux niveaux forment la chaîne complète du bout en bout ?

La Figure I-17 illustre notre première vue des acteurs de la chaîne impactant la QoS de bout en bout. Le premier niveau à considérer pour compléter les propositions existantes est les plates-formes matérielles. Ces équipements physiques, c’est-à-dire, les nœuds et les liens physiques, composants de l'infrastructure du réseau qui héberge les modules logiciels de l'architecture (commutateurs, routeurs, …) assurant la transmission des flux réseau les traversant par la capacité de leurs ressources (CPU, mémoire, interfaces) sont un élément très important à prendre en compte dans la chaîne de bout en bout.

Les services offerts à un utilisateur potentiel

Les résultats présentés dans la section II.1 montrent que les plates-formes matérielles de connectivité et les plates-formes d’accès possibles aux services sont, donc, des tronçons à prendre en compte pour avoir une maîtrise de la chaîne de bout en bout (Figure I-17).

CHAPITRE 3 :ANALYSE ET DISCUSSION 49

Figure I-17: La chaîne d’acteurs de bout en bout

3.1.2 Interaction verticale

Comme présenté ci-dessus (§3.1.1), la QoS de bout en bout est impactée par toute la chaîne, des équipements de transmission jusqu’aux plates-formes d’accès aux services. Et nous avons vu dans les deux chapitres précédents que les propositions existantes ne prennent en considération que le niveau du réseau d’acheminement et le niveau des services. Mais quelle est la vue des propositions existantes des services et leurs impacts ?

Nous avons vu que ce qui est considéré au niveau service (gestion de tampons, correction d’erreurs, et contrôle de congestion) comme élément impactant la QoS est le réseau d’acheminement, leur comportement et réactions restent assimilés au comportement du réseau, c’est-à-dire qu’ils sont conçus pour s’adapter au réseau et pas aux changements qui « arrivent » à la plate-forme de services elle-même comme la saturation d’accès au service ou la saturation des tampons, causes impactant la QoS perçue par l’usager final du service. Les mécanismes basés sur l’observation des variations du RTT (§2.2), par exemple, peuvent conduire à une sous-utilisation du réseau [77], et une pénalisation face aux flux TCP. En plus l’observation de la réponse du réseau doit être lissée par la calcule de la moyenne sur une fenêtre temporelle glissante, afin d’éviter des phénomènes transitoires ou oscillatoires [83] qui augmentent le temps de réaction de l’architecture globale (Réaction suivant le comportement du réseau et non de l’ensemble).

S11 S21 S22 S12 S23 S13 S14 S15 S24 Accès aux services Plateformes de service Acheminement Connectivité

Les propositions présentées pour le routage et la réservation de ressources applicatives franchissent ce pas et considèrent le service comme un niveau à part entière, décorrélé du réseau. Cependant, ces propositions voient ce niveau comme un niveau indépendant du niveau du réseau et sa QoS n’est impacté que par les éléments composants ce niveau. Considération qui n’est pas tout à fait juste car les services applicatifs utilisent le réseau d’acheminement comme moyen de transmission.

Plusieurs travaux ont essayé d’étudier l’interaction entres les différents niveaux à des fins de QoS, notamment, les travaux qui portent sur le Cross-Layer QoS. Ces travaux essayent de proposer un cadre architectural pour la fourniture de la QoS sur les réseaux fixes et mobiles impliquant les cinq couches du modèle OSI (application, transport, réseau, MAC et physique). Parmi ces travaux, nous citons le travail de Chuan [74], où l’auteur propose un cadre de délivrance de QoS de « client à serveur » pour les applications Internet (IP fixe) sensibles au délai. Zhang et al. [75] propose une estimation dynamique de l’état du canal de transmission mobile, la compression d’en-tête et une architecture de cache proxy adaptatif aux conditions du réseau de transmission 3G. Chen et al. [76] propose un ordonnancement basé sur la QoS et un schéma d’adaptation à la puissance du signal afin de coordonner le comportement de la couche basse (physique) pour une consommation optimale des ressources.

Cependant, bien que ces propositions introduisent la notion d’interactivité entre les niveaux architecturaux (application, réseau), ils proposent une organisation statique et figée des architectures et sont focalisés sur l’adaptation du réseau de transmission aux besoins des flux applicatifs. Ces architectures sont adaptées à un type spécifique de services (voix, vidéo, FTP et e-mail), ainsi il est très difficile d’introduire un nouveau service dans ces architectures proposées.

Dans notre démarche et suite aux études et tests que nous avons effectué (§Chapitre 6), nous sommes, donc, convaincu que le niveau service doit être vu comme un niveau à part entière. Certes, la QoS est impactée par le comportement du réseau d’acheminement des flux entre les éléments de ces services mais il faut considérer de façon distincte (pour pouvoir y remédier) les impacts induits par le comportement des éléments composants ce niveau et par la mise en relation des éléments de service que l’on peut offrir aux utilisateurs finaux.

De ce fait, une interaction verticale est nécessaire afin d’apporter une solution intégrée de QoS de bout en bout au lieu d’avoir des solutions isolées, chacune essayant de résoudre une partie du problème sans considérer l’architecture globale.

CHAPITRE 3 :ANALYSE ET DISCUSSION 51