RFC3662 page - 10 - Bless, Nichols & Wehrle

Groupe de travail Réseau

R. Bless, Univ. de Karlsruhe

Request for Comments : 3662

K. Nichols, consultant

Catégorie : Information

K. Wehrle, Univ. de Tuebingen/ICSI

Traduction Claude Brière de L'Isle

décembre 2003



Comportement par domaine (PDB) au moindre effort pour services différenciés



Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.


Notice de copyright

Copyright (C) The Internet Society (2003). Tous droits réservés.


Résumé

Le présent document propose un comportement par domaine (PDB, Per Domain Behavior) de services différenciés dont le trafic peut être "affamé" (bien que la famine ne soit pas strictement exigée) dans un réseau au fonctionnement correct. Ceci s'oppose au modèle du trafic Internet "au mieux" ou "normal", dans lequel une famine prolongée indique des problèmes de réseau. Dans ce sens, le trafic du PDB proposé est transmis avec une priorité "inférieure" à celle du trafic Internet normal "au mieux", donc ce PDB est appelé "au moindre effort" (LE, Lower Effort). L'utilisation de ce PDB permet à un opérateur de réseau de limiter strictement l'effet de son trafic en "au mieux"/"normal" ou de tout autre trafic Internet. Le présent document donne des exemples d'utilisation, mais ne propose pas d'utilisation contraignante de ce PDB pour un type particulier de trafic.


Table des matières

1. Description du PDB au moindre effort 1

2. Applicabilité 2

3. Spécification technique 2

3.1 Classification et conditionnement du trafic 2

3.2 Configuration du PHB 2

4. Attributs 3

5. Paramètres 3

6. Hypothèses 3

7. Exemples d'utilisation 3

8. Expériences 4

9. Considérations sur la sécurité du PDB LE 4

10. Histoire du PDB LE 4

11. Remerciements 4

Appendice A Expériences tirées d'un modèle de simulation 4

A.1 Environnement de la simulation 4

A.2 Résultats de la simulation 6

Références normatives 9

Références pour information 9

Adresse des auteurs 9

Déclaration complète de droits de reproduction 9


1. Description du PDB au moindre effort


Le présent document propose un comportement de services différenciés par domaine [RFC3086] appelé "au moindre effort" (LE, Lower Effort) qui est destiné au trafic de valeur suffisamment faible (où "valeur" peut être interprété de toute façon utile par l'opérateur de réseau) dans lequel tous les autres trafics prennent le pas sur le trafic LE pour la consommation de la bande passante de la liaison du réseau. Une interprétation possible du trafic à "moindre valeur" est sa priorité inférieure dans le temps, qui n'implique pas nécessairement qu'il soit généralement d'importance mineure. De ce point de vue, il peut être considéré comme un équivalent réseau d'une dernière priorité dans les traitements d'un système d'exploitation. Il peut y avoir ou pas des ressources de mémoire (tampon) allouées à ce type de trafic.


Certains réseaux portent du trafic pour lequel la livraison est considérée comme facultative; c'est-à-dire que les paquets de ce type de trafic ne devraient consommer de ressources du réseau que lorsque aucun autre trafic n'est présent. Autrement, l'effet de ce type de trafic sur tous les autres trafics du réseau est strictement limité. Ceci se distingue du trafic "au mieux" (BE, Best Effort) car le réseau ne prend aucun engagement de livrer les paquets LE. À l'opposé, le trafic BE reçoit un engagement implicite de "bonne foi" d'au moins quelques ressources réseau disponibles. Le présent document propose un comportement de services différenciés par domaine de moindre effort (PDB LE, Lower Effort Differentiated Services per-domain behavior) [RFC3086] pour traiter ce trafic "facultatif" dans un domaine de services différenciés.


Il n'y a pas de raison intrinsèque de limiter l'applicabilité du PDB LE à une application ou type de trafic particulier. Il est destiné à être un outil supplémentaire pour les administrateurs dans l'ingénierie des réseaux.


Note : Sauf mention contraire, la terminologie utilisée dans ce document est celle définie dans la [RFC2474].


2. Applicabilité


Un PDB au moindre effort (LE, Lower Effort) est pour l’envoi de trafic sans aucun caractère urgent à travers un domaine DS ou une région DS. On devrait s’attendre à ce que les paquets du PDB LE puissent être retardés ou abandonnés lorsque d’autre trafic est présent. L’utilisation du PDB LE peut aider un opérateur de réseau à déplacer certaines sortes de trafic ou usagers en dehors des heures de pointe. Autrement, ou en plus, les paquets peuvent être destinés au PDB LE lorsque le but est de protéger tous les autres trafics de paquets de la compétition avec l’agrégat LE, tout en ne bannissant pas complètement le trafic LE du réseau. Un PDB LE ne devrait pas être utilisé pour le trafic "Internet normal" d’un abonné, et les paquets ne devraient pas être "dégradés" au PDB LE comme substitut à l’abandon de paquets qui devraient simplement être éliminés comme non autorisés. Le PDB LE est supposé applicable aux réseaux qui ont des capacités inutilisées à certains moments de la journée.


C’est un PDB qui permet aux réseaux de se protéger contre des types de trafic choisis plutôt que de donner à un agrégat de trafic choisi un traitement préférentiel. De plus, il peut aussi exploiter toutes les ressources inutilisées d’autres PDB.


3. Spécification technique

3.1 Classification et conditionnement du trafic


Aucun profil de trafic n’est exigé en ce qui concerne le taux et les salves de paquets au delà des limites imposées par la liaison d’entrée. Il n’est pas nécessaire de limiter l’agrégat LE en utilisant les techniques de bordure dans la mesure où son PHB est configuré de telle façon que les paquets de l’agrégat soient éliminés dans le réseau si des ressources de transmission ne sont pas disponibles. L’architecture de services différenciés de la [RFC2475] permet que les paquets soient marqués en amont du domaine DS ou à la bordure du domaine DS. Lorsque les paquets arrivent pré-marqués avec le DSCP utilisé par le PDB LE, il ne devrait pas être nécessaire que la frontière du domaine DS régule ce marquage ; une classification (MF) supplémentaire pour de tels paquets ne serait nécessaire que s’il y avait des raisons pour que les paquets soient marqués avec un DSCP différent.


Si il n’y a pas d’accord sur un marquage DSCP avec le domaine amont pour un domaine DS qui utilise le PDB LE, la frontière doit inclure un classeur que choisit le groupe de paquets cible LE approprié parmi tous les paquets arrivants et les dirige sur un marqueur qui établit le DSCP approprié. Aucun autre conditionnement de trafic n’est nécessaire.


3.2 Configuration du PHB


On peut utiliser un PHB sélecteur de classe (CS, Class Selector) [RFC2474], un PHB d’utilisation expérimentale/locale (EXP/LU, Experimental/Local Use) [RFC2474], ou un PDB transmission assurée (AF, Assured Forwarding) [RFC2597] comme PHB pour l’agrégat de trafic LE. Le présent document ne spécifie pas le DSCP exact à utiliser à l’intérieur d’un domaine, mais spécifie plutôt les propriétés nécessaires du PHB sélectionné par le DSCP. Si un PHB CS est utilisé, on suggère le sélecteur de classe 1 (DSCP = 001000).


Le PHB utilisé par l’agrégat LE à l’intérieur d’un domaine DS devrait être configuré de telle sorte que ses paquets soient transmis sur la liaison de sortie du nœud lorsque la liaison serait autrement inactive ; conceptuellement, c’est le comportement d’un programmateur round-robin pondéré avec une pondération de zéro.


Un opérateur pourrait choisir de configurer un très petit partage de liaison pour l’agrégat LE et quand même réaliser les objectifs désirés. C’est-à-dire que si le programmateur de la liaison sortante le permet, un petit taux fixé peut être alloué au PHB, mais le comportement au delà de ce taux configuré devrait être que les paquets ne soient transmis que lorsque la liaison serait autrement inactive. Ce comportement pourrait être obtenu, par exemple, en utilisant un programmateur CBQ [CBQ] avec une petite part et une autorisation d’emprunt. Un PHB qui permet aux paquets de l’agrégat LE d’envoyer plus que le taux configuré lorsque des paquets d’autres agrégats de trafic sont en attente de la liaison n’est pas recommandé.


Si un PHB CS est utilisé, noter que cette configuration violera le "DEVRAIT" du paragraphe 4.2.2.2 de la [RFC2474] car CS1 aura une transmission moins réglée que CS0. Le but d’un opérateur en fournissant un PDB LE est une cause suffisante pour violer le DEVRAIT. Si un PHB AF est utilisé, il doit être configuré et un DSCP doit être alloué afin qu’il ne viole pas le "DOIT" du paragraphe 3 de la section 2 de la [RFC2597] qui prévoit une "quantité minimum de ressources de transmission".


4. Attributs


Les flux d’entrée et de sortie de l’agrégat LE peuvent être mesurés mais il n’y a pas d’attribut absolu ou statistique qui ressorte de la définition du PDB. Un opérateur de réseau peut configurer le domaine DS de façon telle qu’une métrique statistique puisse être associée à ce domaine DS. Lorsque le domaine DS est connu pour être lourdement encombré par le trafic d’autres PDB, un opérateur de réseau devrait s’attendre à ne pas voir de paquet (ou très peu) du PDB LE sortir du domaine. Lorsque aucun autre trafic n’est présent, la proportion de l’agrégat LE qui réussit à traverser le domaine ne devrait être limitée que par la capacité du réseau par rapport à l’agrégat de trafic LE en entrée.


5. Paramètres


Il n'en est exigé aucun.


6. Hypothèses


Un réseau qui fonctionne correctement.


7. Exemples d'utilisation


o Applications multimédia [cet exemple a été fourni par Yoram Bernet] :

Beaucoup de gestionnaires de réseau veulent protéger leur réseau de certaines applications, en particulier, des applications multimédia qui utilisent normalement des protocoles non adaptatifs tels que UDP.

En matière de qualité de service, l’accent est principalement mis sur la réalisation d’attributs qui sont meilleurs que au mieux. Ces approches peuvent donner aux gestionnaires de réseau la capacité de contrôler la quantité du trafic multimédia qui reçoit ces performances améliorées, l’excédant étant relégué en au mieux. Cet excédent de trafic peut mettre à mal les ressources du réseau même lorsque il est relégué en au mieux parce qu’il est non adaptable et parce qu’il peut être significatif en volume et en durée. Ces caractéristiques lui permettent d’accaparer les ressources du réseau, compromettant par là les performances des autres applications, plus importantes, qui sont incluses dans l’agrégat de trafic au mieux mais utilisent des protocoles adaptatifs (par exemple, TCP). Il en résulte que les gestionnaires de réseau refusent souvent simplement de permettre que des applications multimédia soient déployées dans des parties à ressources contraintes de leur réseau.

Le PDB LE permet à un gestionnaire de réseau d’autoriser le déploiement d’applications multimédia sans perdre le contrôle des ressources du réseau. Une quantité limitée de trafic multimédia peut (ou non) être allouée aux PDB avec des attributs qui sont meilleurs que au mieux. Le trafic multimédia en excédent peut être empêché de ravager les ressources du réseau en le forçant à prendre le PDB LE.

o Pour Netnews et autre "messagerie en vrac" de l’Internet.

o Pour le trafic "dégradé" provenant de quelque autre PDB lorsque cela ne viole pas les objectifs de fonctionnement d’autres PDB ou du réseau global. Comme noté à la Section 2, LE ne devrait pas être utilisé pour le cas général du trafic rétrogradé, mais peut être utilisé par conception, par exemple, lorsque la diffusion groupée est utilisée avec un service DS à valeur ajoutée, et que survient par conséquent le problème du sous-arbre de réservation négligé (NRS, Neglected Reservation Subtree) [NRS].

o Pour la distribution de contenu, trafic de partage de fichier d’homologue à homologue, et de cette sorte.

o Pour le trafic causé par des moteurs de recherche de la Toile mondiale lorsque ils collectent des informations auprès des serveurs.


8. Expériences


Les auteurs sollicitent d'autres expériences pour cette section. Les résultats des simulations sont présentés et discutés dans l'Appendice A.


9. Considérations sur la sécurité du PDB LE


Il n'y a pas d'exposition spécifique de la sécurité pour ce PDB. Voir les considérations générales sur la sécurité dans la [RFC2474] et la [RFC2475].


10. Histoire du PDB LE


Le nom précédent de ce PDB, "traitement en vrac", était vaguement fondé sur le terme du service postal des États Unis pour le courrier à très faible priorité, envoyé à tarif réduit : il recouvre une livraison à moindre coût où les éléments ne sont pas traités avec le même soin ou livrés aussi rapidement que les éléments avec l’affranchissement de première classe. Finalement, le nom a été changé en "moindre effort", parce que les auteurs et les autres membres du groupe de travail DiffServ estimaient que le nom devrait être plus générique afin de ne pas impliquer de contraintes pour l’utilisation du PDB pour un type particulier de trafic (à savoir des données en vrac).


La notion d’avoir quelque chose "d’inférieur à au mieux" a été soulevée dans le groupe de travail Diffserv, en particulier par Roland Bless et Klaus Wehrle dans leurs projets Internet [LBE] et [LE] et par Yoram Bernet pour les applications multimédia d’entreprise. Une de ses premières applications était de faire un nouveau marquage des paquets au sein des groupes de diffusion groupée [NRS]. Donc, les discussions précédentes étaient centrées sur la création d’un nouveau PHB. Cependant, les auteurs originaux (Brian Carpenter et Kathleen Nichols) pensaient que ce n’était pas nécessaire et le présent document a été écrit pour expliquer précisément comment obtenir moins que au mieux sans un nouveau PHB.


11. Remerciements


Yoram Bernet a contribué à des quantités significatives du texte de la section "Exemples" de ce document et fourni d’autres commentaires utiles qui ont aidé à la publication. D’autres membres du groupe de travail Diffserv ont suggéré que le PDB LE était nécessaire pour le trafic Napster, en particulier dans les universités. Des remerciements tout particuliers à Milena Neumann pour ses inlassables efforts pour effectuer les simulations qui sont décrites dans l’Appendice A.






Appendice A Expériences tirées d'un modèle de simulation


L’intention de cet appendice est de montrer qu’un PDB moindre effort avec le comportement décrit dans ce document peut être réalisé avec respectivement des mises en œuvre et des PHB différents. Globalement, chacune de ces variantes montre le comportement désiré mais aussi des différences mineures dans certaines situations de charge de trafic. Cette comparaison pourrait rendre intéressant pour un opérateur de réseau le choix d’une variante de réalisation.


A.1 Environnement de la simulation


Le petit domaine DiffServ montré à la Figure 1 a été utilisé pour simuler le PDB LE. Il y a trois sources de trafic principales (S1 à S3) décrites sur la gauche de la figure. La source S1 envoie cinq flux TCP agrégés (A1-A5) à des receveurs, respectivement R1 à R5. Chaque flux agrégé Ax consiste en 20 connexions TCP, où chaque agrégat subit un temps d’aller-retour différent entre 10 ms et 250 ms. Il y a deux sources de trafic en vrac. B1 consiste en 100 connexions TCP qui envoient autant de données que possible à R6, et B2 est un seul flux UDP qui envoie aussi autant que possible à R7.


...................

. . R1

. . /

. . /-R2

. . /

S1==**=>[BR1] [BR4]==**==>---R3

. \\ // . \

. \\ // . \-R4

. ** ** . \

. \\ // . R5

. \\ // .

S2=++=>[BR2]-++-[IR1]==**==++==::==[IR2] .

(Vrac) . // \\ .

. // :: .

. :: \\ .

. // ++ .

.// \\.

S3==::==>[BR3] [BR5]==++==>R6

(UDP) . . ||

. . ||

. . ::

.................... ||

VV

R7


Figure 1 : Domaine DiffServ avec différents flux


Pour montrer les avantages de l’utilisation du PDB LE à la place du PDB normal au mieux (BE) [RFC3086], on utilise différents scénarios :

A) B1 et B2 ne sont pas présents, c’est-à-dire, la situation "normale" sans données en vrac. A1-A5 utilisent le PDB BE.

B) B1 et B2 utilisent aussi le PDB BE pour leur trafic.

C) B1 et B2 utilisent le PDB LE pour leur trafic avec des mises en œuvre de PHB différentes :

1) PHB avec mise en file d’attente prioritaire (PG, Priority Queueing)

2) PHB avec mise en file d’attente équitable pondérée (WFQ, Weighted Fair Queueing)

3) PHB avec détection précoce aléatoire (RED, Random Early Detection) pondérée (WRED, Weighted RED)

4) PHB avec WFQ et RED


C1) représente le cas où il n’y a pas de ressources allouées pour le PDB LE, c’est-à-dire que le trafic LE n’est transmis que si il y a des ressources inutilisées. Dans les scénarios C2) à C4), un partage de bande passante de 10 % a été alloué pour le PDB LE. Les paramètres de RED ont été réglés à w_q = 0,1 et max_p = 0,2. Dans le scénario C2), deux files d’attente à abandon de queue ont été utilisées pour BE et LE, et la programmation WFQ a été établie avec une pondération de 9:1 pour le ratio de BE:LE. Dans le scénario C3), une longueur de queue totale de 200 000 octets a été utilisée avec les seuils suivants : min_th_BE = 19 000, max_th_BE = 63 333, min_th_LE = 2346, max_th = 7037. WRED permet de marquer les paquets avec BE ou LE au sein du même microflux (par exemple, en laissant les applications pré marquer les paquets selon leur importance) sans causer de réarrangement des paquets au sein du microflux. Dans le scénario C4), chaque file d’attente a une longueur de 50 000 octets avec les mêmes seuils de min_th = 18 000 et max_th = 48 000 octets. Les paramètres de WFQ sont les mêmes que dans C2).


La bande passante de la liaison entre IR1 et IR2 est limitée à 1200 kbit/s, créant donc un embouteillage dans le réseau pour les situations suivantes. Dans toutes les situations, les 20 connexions TCP au sein de chaque flux agrégé Ax (s’écoulant de S1 à Rx) utilisent le PDB au mieux. L’envoyeur S2 transmet des flux en vrac B1 (consistant en 100 connexions TCP avec R6) avec un taux agrégé de 550 kbit/s, tandis que l’envoyeur UDP S3 transmet au taux de 50 kbit/s.


Les quatre situations différentes avec variation de charge de trafic pour les flux Ax (au niveau application) ont été simulées.


Situation

I

II

III

IV

Débit d’envoi S1 [kbit/s]

1200

1080

1800

800

Débit d’envoi S2 [kbit/s]

550

550

550

550

Débit d’envoi S3 [kbit/s]

50

50

50

50

Bande passante IR1 -> IR2

1200

1200

1200

1200

Charge au mieux (S1)

100 %

90 %

150 %

67 %

Charge totale pour la liaison IR1->IR2

150 %

140 %

200 %

117 %


Dans la situation I, il n’y a pas de ressources inutilisées laissées pour les flux B1 et B2. Dans la situation II, il y a une bande passante résiduelle de 10 % de la liaison embouteillée entre IR1 et IR2. Dans la situation III, la charge de trafic de A1-A5 est de 50 % supérieure à la capacité de la liaison embouteillée. Dans la situation IV, A1-A5 consomment seulement 2/3 de la capacité de la liaison embouteillée. B1 et B2 exigent ensemble 50 % de la capacité de la liaison embouteillée.


La simulations a été effectuée avec l’outil de simulation d’événement discret librement disponible OMNeT++ et un ensemble convenable de mécanismes de QS [SimKIDS]. Les résultats des différents scénarios de simulation sont exposés à la section suivante.


A.2 Résultats de la simulation


Les paramètres de QS énumérés dans les tableaux suivants sont moyennés sur les 160 premières secondes de la transmission. Les résultats de la situation I sont montrés à la Figure 2. Lorsque le PDB BE est utilisé pour la transmission des flux en vrac B1 et B2 dans le cas B), on peut voir que les flux A1-A5 accélèrent leur taux d’envoi pour permettre la transmission des flux en vrac B1 et B2. Dans le cas C1), pas un seul paquet n’est transmis au receveur parce que tous les paquets sont abandonnés au sein de IR1, protégeant par là les flux Ax des flux Bx. Dans le cas C2), B1 et B2 consomment toutes les ressources jusqu’à la limite configurée de 10 % de la bande passante de la liaison, mais pas plus. C3) limite aussi la part des flux B1 et B2, mais pas aussi précisément qu’avec WFQ. C4) montre une perte de paquets légèrement supérieure pour les flux Ax du fait de la gestion active de file d’attente.


+-------------------------+---------+-----------------------------------+

| | A) | Transfert en vrac avec PDB : |

| Paramètres de QS | Pas de | B) | C) moindre effort |

| |transfert| au | 1) 2) 3) 4) |

| Flux |en vrac |mieux | PQ | WFQ | WRED |RED&WFQ|

+----------------+--------+----------------+------+------+------+-------+

| | A1 | 240 | 71 | 240 | 214 | 225 | 219 |

| | A2 | 240 | 137 | 240 | 216 | 223 | 218 |

| | A3 | 240 | 209 | 240 | 224 | 220 | 217 |

| Débit | A4 | 239 | 182 | 239 | 222 | 215 | 215 |

| [kbit/s] | A5 | 238 | 70 | 238 | 202 | 201 | 208 |

| | B1 | - | 491 | 0 | 82 | 85 | 84 |

| | B2 | - | 40 | 0 | 39 | 31 | 38 |

+----------------+--------+---------+------+------+------+------+-------+

|Débit total | normal | 1197 | 669 | 1197 | 1078 | 1084 | 1078 |

| [kbit/s] | en vrac| - | 531 | 0 | 122 | 116 | 122 |

+----------------+--------+---------+------+------+------+------+-------+

| | A1 | 0 | 19,3 | 0 | 6,3 | 5,7 | 8,6 |

| | A2 | 0 | 17,5 | 0 | 6,0 | 5,9 | 8,9 |

| Perte de | A3 | 0 | 10,2 | 0 | 3,2 | 6,2 | 9,1 |

| paquet | A4 | 0 | 12,5 | 0 | 4,5 | 6,6 | 9,3 |

| [%] | A5 | 0 | 22,0 | 0 | 6,0 | 5,9 | 9,0 |

| | B1 | - | 10,5 | 100 | 33,6 | 38,4 | 33,0 || | B2 | - | 19,6 | 100 | 19,9 | 37,7 | 22,2 |

+----------------+--------+---------+------+------+------+------+-------+

| Taux de perte | normal | 0 | 14,9 | 0 | 5,2 | 6,1 | 9,0 |

| de paquet [%] | en vrac| 0 | 11,4 | 100 | 29,5 | 38,2 | 29,7 |

+----------------+--------+---------+------+------+------+------+-------+

| Données transm-| | | | | | | |

| ises [Moctet] | normal | 21,9 | 12,6 | 21,9 | 19,6 | 20,3 | 20,3 |

+----------------+--------+---------+------+------+------+------+-------+


Figure 2 : Situation I – le trafic au mieux utilise 100 % de la bande passante disponible


Les résultats de la situation II sont montrés à la Figure 3. Dans le cas C1), le trafic LE obtient exactement 10 % de la bande passante résiduelle qui n’est pas utilisée par les flux Ax. Les cas C2) et C4) montrent des résultats similaires par rapport à C1), tandis sue le cas C3) abandonne aussi des paquets des flux A1-A5 du fait de la gestion active de file d’attente.






+-------------------------+---------+-----------------------------------+

| | A) | Transfert en vrac avec PDB : |

| Paramètres de QS | pas de | B) | C) Moindre effort |

| |transfert| au | 1) 2) 3) 4) |

| Flux |en vrac |mieux | PQ | WFQ | WRED |RED&WFQ|

+----------------+--------+---------+------+------+------+------+-------+

| | A1 | 216 | 193 | 216 | 216 | 211 | 216 |

| | A2 | 216 | 171 | 216 | 216 | 211 | 216 |

| | A3 | 216 | 86 | 216 | 216 | 210 | 216 |

| Débit | A4 | 215 | 121 | 215 | 215 | 211 | 215 |

| [kbit/s] | A5 | 215 | 101 | 215 | 215 | 210 | 215 |

| | B1 | - | 488 | 83 | 83 | 114 | 84 |

| | B2 | - | 39 | 39 | 39 | 33 | 38 |

+----------------+--------+---------+------+------+------+------+-------+

|Débit total | normal | 1078 | 672 | 1077 | 1077 | 1053 | 1077 |

| [kbit/s] |en vrac | - | 528 | 122 | 122 | 147 | 122 |

+----------------+--------+---------+------+------+------+----+-+-------+

| | A1 | 0 | 9,4 | 0 | 0 | 1,8 | 0 |

| | A2 | 0 | 14,6 | 0 | 0 | 2,0 | 0 |

| | A3 | 0 | 22,4 | 0 | 0 | 2,1 | 0 |

| Perte de paquet| A4 | 0 | 15,5 | 0 | 0 | 1,8 | 0 |

| [%] | A5 | 0 | 17,4 | 0 | 0 | 1,9 | 0 |

| | B1 | - | 11,0 | 32,4 | 32,9 | 35,7 | 33,1 |

| | B2 | - | 21,1 | 20,3 | 20,7 | 34,0 | 22,2 |

+----------------+--------+---------+------+------+------+------+-------+

| Taux total de | normal | 0 | 14,9 | 0 | 0 | 1.9 | 0 |

| perte paquet[%]|en vrac | - | 12,0 | 28,7 | 29,1 | 35,3 | 29,8 |

+----------------+--------+---------+------+------+------+------+-------+

| Données trans- | | | | | | | |

| mises [Moctet] | normal | 19,8 | 12,8 | 19,8 | 19,8 | 19,5 | 19,8 |

+----------------+--------+---------+------+------+------+------+-------+


Figure 3 : Situation II - la charge de trafic au mieux utilise 90 % de la bande passante disponible


Les résultats des simulations pour la situation III sont décrits à la Figure 4. Du fait de la surcharge causée par les flux A1-A5, des paquets sont abandonnés dans tous les cas. Les flux en vrac B1 et B2 obtiennent presque leur débit maximum dans le cas B). Comme on peut s’y attendre, dans le cas C1) tous les paquets de B1 et B2 sont abandonnés, dans les cas C2) et C4) la consommation de ressources des données en vrac est limitée à la part configurée de 10 %. Là encore, la mise en œuvre de WRED dans C3) n’est pas aussi précise que les variantes WFQ et laisse plus de trafic BE passer à travers IR1.


+-------------------------+---------+-----------------------------------+

| | A) | Transfert en vrac avec PDB : |

| Paramètres de QS | pas de | B) | C) Moindre effort |

| |transfert| au | 1) 2) 3) 4) |

| Flux |en vrac |mieux | PQ | WFQ | WRED |RED&WFQ|

+----------------+--------+---------+------+------+------+------+-------+

| | A1 | 303 | 136 | 241 | 298 | 244 | 276 |

| | A2 | 316 | 234 | 286 | 299 | 240 | 219 |

| | A3 | 251 | 140 | 287 | 259 | 236 | 225 |

| Débit | A4 | 168 | 84 | 252 | 123 | 209 | 219 |

| [kbit/s] | A5 | 159 | 82 | 132 | 101 | 166 | 141 |

| | B1 | - | 483 | 0 | 83 | 73 | 83 |

| | B2 | - | 41 | 0 | 38 | 31 | 38 |

+----------------+--------+---------+------+------+------+------+-------+

|Débit total |normal | 1199 | 676 | 1199 | 1079 | 1096 | 1079 |

| [kbit/s] |en vrac | - | 524 | 0 | 121 | 104 | 121 |

+----------------+--------+---------+------+------+------+------+-------+

| | A1 | 9,6 | 17,6 | 12,1 | 9,3 | 8,6 | 12,8 |

| | A2 | 8,5 | 13,6 | 8,4 | 9,8 | 8,1 | 14,5 |

| | A3 | 8,8 | 18,7 | 7,7 | 11,6 | 7,8 | 13,6 |

| Perte de paquet| A4 | 14,9 | 22,3 | 11,2 | 18,9 | 8,2 | 12,4 |

| [%] | A5 | 12,8 | 19,0 | 15,6 | 19,7 | 8,3 | 14,3 |

| | B1 | - | 11,9 | 100 | 32,1 | 39,5 | 33,0 |

| | B2 | - | 17,3 | 100 | 22,5 | 37,7 | 22,8 |

+----------------+--------+---------+------+------+------+------+-------+

| Taux total de | normal | 10,4 | 17,3 | 10,3 | 12,2 | 8,2 | 13,4 |

| perte paquet[%]|en vrac | - | 12,4 | 100 | 29,1 | 39,0 | 29,9 |

+----------------+--------+---------+------+------+------+------+-------+

| Données trans- | | | | | | | |

| mises [Moctet] | normal | 22,0 | 12,6 | 22,0 | 20,2 | 20,6 | 20,3 |

+----------------+--------+---------+------+------+------+------+-------+


Figure 4 : Situation III - la charge de trafic au mieux est de 150 %


Dans la situation IV, 33 % ou 400 kbit/s ne sont pas utilisés par les flux Ax et les résultats sont donnés à la Figure 5. Dans le cas B) où les flux de données en vrac B1 et B2 utilisent le PDB BE, les paquets des flux Ax sont abandonnés, tandis que dans les cas C1)-C4) les flux Ax sont protégés des flux en vrac B1 et B2. Donc, en utilisant le PDB LE pour les flux Bx, ceux-là n’obtiennent que la bande passante résiduelle de 400 kbit/s mais pas plus. Les paquets des flux Ax ne sont pas affectés par le trafic Bx dans ces cas.


+-------------------------+---------+-----------------------------------+

| | A) | Transfert en vrac avec PDB : |

| Paramètres de QS | pas de | B) | C) Moindre effort |

| |transfert| au | 1) 2) 3) 4) |

| Flux |en vrac |mieux | PQ | WFQ | WRED |RED&WFQ|

+----------------+--------+---------+------+------+------+------+-------+

| | A1 | 160 | 140 | 160 | 160 | 160 | 160 |

| | A2 | 160 | 124 | 160 | 160 | 160 | 160 |

| | A3 | 160 | 112 | 160 | 160 | 160 | 160 |

| Débit | A4 | 160 | 137 | 160 | 160 | 159 | 160 |

| [kbit/s] | A5 | 159 | 135 | 159 | 159 | 159 | 159 |

| | B1 | - | 509 | 361 | 362 | 364 | 362 |

| | B2 | - | 43 | 40 | 39 | 38 | 40 |

+----------------+--------+---------+------+------+------+------+-------+

|Débit total | normal | 798 | 648 | 798 | 798 | 797 | 798 |

| [kbit/s] |en vrac | - | 551 | 401 | 401 | 402 | 401 |

+----------------+--------+---------+------+------+------+------+-------+

| | A1 | 0 | 9,2 | 0 | 0 | 0 | 0 |

| | A2 | 0 | 12,2 | 0 | 0 | 0 | 0 |

| | A3 | 0 | 14,0 | 0 | 0 | 0 | 0 |

| Perte de paquet| A4 | 0 | 9,3 | 0 | 0 | 0 | 0 |

| [%] | A5 | 0 | 6,6 | 0 | 0 | 0 | 0 |

| | B1 | - | 7,3 | 21,2 | 21,8 | 25,0 | 21,3 |

| | B2 | - | 14,3 | 19,4 | 20,7 | 24,5 | 20,7 |

+----------------+--------+---------+------+------+------+------+-------+

| Perte totale de| normal | 0 | 10,2 | 0 | 0 | 0 | 0 |

| paquets [%] |En vrac | - | 8,0 | 21,0 | 21,7 | 25,0 | 21,2 |

+----------------+--------+---------+------+------+------+------+-------+

| Données trans- | | | | | | | |

| mises [Moctet] | normal | 14,8 | 12,1 | 14,8 | 14,8 | 14,7 | 14,7 |

+----------------+--------+---------+------+------+------+------+-------+


Figure 5 : Situation IV – la charge de trafic au mieux est de 67 %


En résumé, tous les différents scénarios montrent que le trafic BE "normal" peut être protégé efficacement du trafic du PDB LE. Soit aucun paquet ne passe si il ne reste pas de bande passante résiduelle (le trafic LE est affamé) soit le trafic du PDB LE ne peut consommer les ressources que jusqu’à une limite configurable.


De plus, les résultats prouvent qu’un transfert massif de données peut affecter de façon contraire le trafic BE "normal" (par exemple, 14,9 % de perte de paquets dans les situations I et II, et même 10,2% dans la situation IV) dans les situations où on utilise pas le PDB LE.


Donc, alors que toutes les variantes de réalisation du PDB LE présentées satisfont au comportement désiré de protection du trafic BE, elles montrent aussi de petites différences de détail. Un opérateur de réseau a l’opportunité de choisir une méthode de réalisation pour s’adapter au comportement désiré (ce qui est – après la preuve de l’efficacité de LE – le second objectif de cet appendice). Par exemple, si les opérateurs veulent affamer complètement le trafic LE en période d’encombrement, ils peuvent choisir PQ. Cela cause une famine complète pour le trafic LE, et pas un seul paquet ne va passer en cas de charge pleine ou de surcharge.


D’un autre côté, pour les opérateurs de réseau qui veulent permettre une petite quantité de débit dans le PDB LE, une des autres variantes serait un meilleur choix.


En se référant à cela, la mise en œuvre de WFQ a montré un comportement légèrement plus robuste avec PQ, mais avait des problèmes avec les flux TCP synchronisés. Le comportement WRED dépend fortement des caractéristiques réelles du trafic et les taux de perte de paquet sont souvent plus élevés par rapport aux autres mises en œuvre, alors que l’équité est meilleure entre connexions TCP. La solution combinée de WFQ avec RED a montré le meilleur comportement global, lorsque l’intention de l’opérateur est de conserver un débit faible mais non nul dans le PDB LE.


Références normatives


[RFC2474] K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ par RFC3168, RFC3260) (P.S.)


[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre 1998. (MàJ par RFC3260)


[RFC3086] K. Nichols, B. Carpenter, "Définition des comportements de services différenciés par domaine et règles de leur spécification", avril 2001. (Information)


Références pour information


[RFC2597] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Groupe PHB Transmission assurée", juin 1999. (MàJ par RFC3260) (P.S.)


[CBQ] Floyd, S. et V. Jacobson, "Link-sharing et Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3, n° 4, pp. 365-386, août 1995.


[LBE] Bless, R. et K. Wehrle, "A Lower Than Best-Effort Per-Hop Behavior", non publié comme RFC, septembre 1999.


[LE] Bless, R. et K. Wehrle, "A Limited Effort Per-Hop Behavior", non publié comme RFC, février 2001.


[SimKIDS] Wehrle, K., Reber, J. et V. Kahmann, "A simulation suite for Internet nodes with the ability to integrate arbitrary Quality of Service behavior", dans Proceedings of Communication Networks And Distributed Systems Modeling And Simulation Conference (CNDS 2001), Phoenix (AZ), USA, pp. 115-122, janvier 2001.


[NRS] Bless, R. et K. Wehrle, "Group Communication in Differentiated Services Networks", dans Proceedings of IEEE International Workshop on "Internet QoS", Brisbane, Australia, IEEE Press, pp. 618-625, mai 2001.


Adresse des auteurs


Roland Bless

Kathleen Nichols

Klaus Wehrle

Institute of Telematics,

Universitaet Karlsruhe (TH)

325M Sharon Park Drive #214

University of Tuebingen,

Computer Networks et Internet

Zirkel 2

Menlo Park, CA 94025

Morgenstelle 10c, 72076 Tuebingen, Deutchland

76128 Karlsruhe

mél : knichols@ieee.org

& International Computer Science Institute (ICSI)

Deutchland


1947 Center Street, Berkeley, CA, 94704, USA

mél : bless@tm.uka.de


mél : Klaus.Wehrle@uni-tuebingen.de

http://www.tm.uka.de/~bless/


URI : http://net.informatik.uni-tuebingen.de/~wehrle/


Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2002). Tous droits réservés.


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si c'est nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.