Dans cette image, il y a deux aspects int\u00e9ressants :<\/p>\n
- \n
- on comprend ais\u00e9ment que si l’\u00e9metteur des ballons acc\u00e9l\u00e8re le rythme ou si plusieurs joueurs vous lancent des ballons vous risquez d’\u00eatre rapidement d\u00e9bord\u00e9 ! R\u00e9sultat, vous allez perdre des ballons (ils vont tomber par terre <\/em>!). C’est la m\u00eame chose pour la transmission de donn\u00e9es. Vous allez perdre des trames ! Vous \u00eates confront\u00e9 \u00e0 une congestion en entr\u00e9e<\/strong> ! Le d\u00e9bit d’entr\u00e9e est sup\u00e9rieur \u00e0 votre capacit\u00e9 de traitement<\/strong> ! Si vous vous retourniez plus vite (l’image du traitement) vous pourriez prendre plus de ballons en charge !<\/li>\n
- on peut \u00e9galement deviner que si votre capacit\u00e9 de traitement est sup\u00e9rieur, vous vous retournez plus vite pour passer vos ballons. Il est alors possible que le joueur \u00e0 qui vous passez le ballon soit \u00e9galement d\u00e9bord\u00e9. Vos ballons vont tomber, vous \u00eates confront\u00e9 \u00e0 une congestion en sortie<\/strong> ! La capacit\u00e9 de traitement est sup\u00e9rieure au d\u00e9bit de sortie<\/strong> ! Il est int\u00e9ressant de remarquer que plus vous \u00eates performant, plus vous risquez d’\u00eatre en congestion en sortie !<\/li>\n<\/ul>\n
Vous l’aurez compris, dans cette image, le joueur qui vous lance les ballons est le lien d’entr\u00e9e, vous \u00eates l’\u00e9quipement de commutation ou routage, l’autre joueur est votre lien de sortie !<\/p>\n
Perdre des donn\u00e9es, est-ce grave ?<\/h2>\n
Est-ce maintenant tr\u00e8s grave de perdre des trames<\/strong> ? Oui et non !<\/p>\n
On peut en perdre un peu, \u00e7a ne changera pas la face du monde, les protocoles sont l\u00e0 pour veiller \u00e0 ces probl\u00e8mes, il en r\u00e9sultera simplement une r\u00e9\u00e9mission des donn\u00e9es par un des \u00e9quipements de la cha\u00eene (station \u00e9mettrice ou \u00e9quipement de commutation selon les protocoles et les architectures), nous avons vu cela dans le cours OSI.<\/p>\n
Par contre si on en perd beaucoup, les r\u00e9\u00e9missions constantes vont avoir pour r\u00e9sultat d’allonger le d\u00e9lai de r\u00e9ponse<\/strong>, un fichier qui devait \u00eatre transf\u00e9r\u00e9 en 10 secondes le sera en 20, 30 ou pire ! L’utilisateur derri\u00e8re son \u00e9cran recevra ses masques avec un d\u00e9lai insupportable, et vous … tombera sur le poil<\/em> !<\/p>\n
Enfin vous serez confront\u00e9 \u00e0 un dernier effet \u00ab\u00a0pervers\u00a0\u00bb. Plus il y a de congestion, plus vous perdez de donn\u00e9es. Et plus vous perdez de donn\u00e9es, plus il y a des tentatives de r\u00e9\u00e9mission par les protocoles, donc plus il y a de donn\u00e9es \u00e0 transf\u00e9rer et donc plus il y a de congestion ! L’effet \u00ab\u00a0boule de neige\u00a0\u00bb, quoi !<\/p>\n
Donc on ne peut pas laisser faire ! Il y a, peut-\u00eatre, plusieurs m\u00e9thodes pour s’en sortir :<\/p>\n
- \n
- l’utilisation de buffers<\/strong> : m\u00e9thode la plus basique mais qui ne va pas tr\u00e8s loin !<\/li>\n
- augmenter le d\u00e9bit<\/strong> : tr\u00e8s facile mais pas vraiment du go\u00fbt du directeur des achats ! D’ailleurs est-ce que cela sera efficace longtemps ?<\/li>\n
- utiliser un support \u00e0 bande passante variable<\/strong> : solution tr\u00e8s int\u00e9ressante ! Mais il y a encore mieux !<\/li>\n
- utiliser un support \u00e0 bande passante variable et asym\u00e9trique<\/strong> : de mieux en mieux ! On a un sens de transmission plus rapide que l’autre ! Mais quelle est la contre-partie ?<\/li>\n
- mettre en place une priorisation des flux<\/strong> : hum … C’est vraiment tr\u00e8s bien, mais attention \u00e0 ce que l’on comprend par l\u00e0 ! Il y a des id\u00e9es toutes faites que je vais me faire un plaisir de mettre par terre.<\/li>\n
- mettre en \u0153uvre une gestion de flux<\/strong> : Alors l\u00e0, c’est imparable ! Bravo ! Oui, sauf que \u00e7a ne r\u00e9souts pas le probl\u00e8me de congestion ! Le contr\u00f4le de flux s’active seulement s’il y a justement de la congestion !<\/li>\n<\/ul>\n
Nous allons donc \u00e9tudier ci-dessous ces diff\u00e9rentes solutions.<\/p>\n
Buffer ! Sauve-moi …<\/h2>\n
Soyons clair ! Tous les \u00e9quipements de transmission sont \u00e9quip\u00e9s de buffers (m\u00e9moires tampons<\/strong> en fran\u00e7ais dans le texte<\/em> !) en entr\u00e9e et en sortie. Pour comprendre comment \u00e7a marche (alors l\u00e0, je descends au niveau novice <\/em>!) prenons une autre image que les ballons (les jeux de baballes n’ont jamais \u00e9t\u00e9 ma tasse de th\u00e9<\/em>). Utilisons l’image de la baignoire (ou du bac \u00e0 douche, du lavabo ou de l’\u00e9vier selon l’endroit o\u00f9 vous vous lavez <\/em>!). La baignoire c’est sympa, un petit bain chaud j’aime \u00e7a de temps en temps (heu .. OK .. Vous vous en fichez<\/em> !).<\/p>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/BAIGNOIRE.gif\")
La baignoire c’est le buffer, le robinet c’est le lien d’entr\u00e9e, l’eau c’est les bits et le tuyau d’\u00e9vacuation c’est le lien de sortie (j’ai toujours dit que les t\u00e9l\u00e9coms n’\u00e9taient pas plus compliqu\u00e9es que la plomberie !<\/em>). En plus notre baignoire est assez sympa parce qu’elle est pr\u00e9vu pour deux ! Mais pas de faux espoirs ! Il y a deux compartiments s\u00e9par\u00e9s par une cloison (pas de chance, hein ?<\/em>). Cette cloison a un trou en bas qui permet \u00e0 l’eau qui vient du compartiment 1, o\u00f9 est plac\u00e9 le robinet, de passer dans le compartiment 2, o\u00f9 est plac\u00e9 le tuyau d’\u00e9vacuation ! Que se passe-t-il si on ouvre le robinet ?<\/p>\n<\/p>\n
L’eau arrive dans le compartiment 1, s’\u00e9coule gr\u00e2ce \u00e0 la pente (et oui ! Avez-vous d\u00e9j\u00e0 remarqu\u00e9 qu’il y avait une petite pente dans une baignoire ?<\/em>) passe \u00e0 travers le trou de la cloison, arrive dans le compartiment 2 et s’\u00e9chappe par le trou d’\u00e9vacuation ! Vous l’aurez compris, la taille du trou (et \u00e9ventuellement l’inclinaison de la pente) symbolise ici la vitesse de traitement de l’\u00e9quipement (heu … de la baignoire !<\/em>). Que peut-il se passer ?<\/p>\n
1. Les tailles du trou de cloison et du tuyau d’\u00e9vacuation (j’oublie la pente que l’on consid\u00e9rera, bien … pentu !<\/em>) sont sup\u00e9rieures \u00e0 celle du robinet. L’eau passe sans probl\u00e8me dans le compartiment 2 puis s’\u00e9chappe. Tout va bien !<\/p>\n
2. La taille du tuyau d’\u00e9vacuation est inf\u00e9rieure \u00e0 celles du trou de cloison et du robinet (il y a probablement encore des cheveux dans le siphon ! Vous connaissez \u00e7a aussi, non ?<\/em>). Par contre le trou de cloison est sup\u00e9rieur \u00e0 la taille du robinet. Dans ce cas, l’eau s’\u00e9coule correctement dans le compartiment 2 o\u00f9 elle va s’accumuler puisqu’elle ne peut \u00eatre \u00e9vacu\u00e9 aussi vite qu’elle arrive ! Si vous arr\u00eatez le robinet, l’eau du compartiment 2 va s’\u00e9couler doucement et il n’y aura pas de d\u00e9g\u00e2t. Par contre si vous continuez trop longtemps le compartiment 2 finira par d\u00e9border (le premier qui se l\u00e8ve pour m’opposer le principe des vases communicants est pri\u00e9 de sortir ! Je fais ce que je veux ! Dans MA baignoire il n’y a pas de vases communicants ! Compris ?<\/em>). Vous avez donc d\u00e9pass\u00e9 les capacit\u00e9s de votre buffer de sortie !<\/p>\n
3. La taille du trou de cloison est inf\u00e9rieure \u00e0 celle du robinet. L’eau va s’\u00e9couler plus lentement dans le compartiment 2 qu’elle n’arrive par le robinet. Si le tuyau d’\u00e9vacuation est sup\u00e9rieur \u00e0 celui de la cloison vous n’aurez pas de remplissage du compartiment 2, par contre le premier risque de d\u00e9border si vous ne ralentissez pas le d\u00e9bit du robinet. Vous d\u00e9passerez dans ce cas les capacit\u00e9s de votre buffer d’entr\u00e9e ! \u00c9ventuellement si le trou d’\u00e9vacuation est dans le m\u00eame temps inf\u00e9rieur au trou de cloison vous d\u00e9passerez \u00e9galement les capacit\u00e9s de votre buffer de sortie, le compartiment 2 va se remplir ! (La totale, quoi ! Sortez la serpilli\u00e8re, \u00e7a fuit de partout !<\/em>).<\/p>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/BUFFER.gif\")
Vous l’aurez donc compris (du moins je l’esp\u00e8re<\/em>), les buffers vous permettent de gagner un peu de temps, vous pouvez absorber une charge passag\u00e8re mais pas constante, sinon vous obtiendrez \u00e9galement de la congestion !<\/p>\nEn fait, comme le montre le graphe D ci-contre issu du sch\u00e9ma du chapitre pr\u00e9c\u00e9dent, le buffer va reporter dans le temps la transmission d’une pointe de trafic momentan\u00e9e. On parle souvent de \u00ab\u00a0lissage<\/strong>\u00a0\u00bb du trafic !<\/p>\n
<\/p>\n
<\/p>\n
Et si on augmente le d\u00e9bit ?<\/h2>\n
L’augmentation de d\u00e9bit s’applique pour un probl\u00e8me de congestion en sortie, cela revient \u00e0 augmenter la taille du tuyau d’\u00e9vacuation de la baignoire ! Pour un probl\u00e8me de congestion en entr\u00e9e il faut :<\/p>\n
- \n
- soit diminuer le d\u00e9bit d’entr\u00e9e<\/strong> (le directeur des achats est content, l’utilisateur beaucoup moins !<\/em>)<\/li>\n
- soit augmenter la capacit\u00e9 de traitement<\/strong> de l’\u00e9quipement en congestion (\u00e7a va moins plaire au directeur des achats !)<\/li>\n<\/ul>\n
En v\u00e9rit\u00e9 on ne traite g\u00e9n\u00e9ralement que de probl\u00e8mes de congestion en sortie ! En entr\u00e9e on se limite \u00e0 installer des \u00e9quipements aux performances suffisantes pour absorber le d\u00e9bit d’entr\u00e9e (ou la somme des d\u00e9bits d’entr\u00e9e\/sortie). Il est \u00e9vident que pour transf\u00e9rer 2 000 ballons \u00e0 la minute il vaut mieux avoir un lapin, qu’une tortue !<\/p>\n
En supposant que vous ayez r\u00e9ussi \u00e0 convaincre votre directeur des achats, qu’il est imp\u00e9ratif, sous peine de r\u00e9volte des utilisateurs, de monter en d\u00e9bit pour des probl\u00e8mes de congestion en sortie. Pensez-vous avoir r\u00e9gl\u00e9 tout vos probl\u00e8mes ? Peut-\u00eatre … Mais pas si s\u00fbr ! Avant de prendre cette d\u00e9cision il vous faut prendre en compte les remarques suivantes :<\/p>\n
1.<\/span><\/strong> Quel type de trafic le lien v\u00e9hicule-t-il ? Des donn\u00e9es transactionnelles, du FTP, du SMTP ou de l’Internet\/Intranet (HTTP) ? Peut-\u00eatre un peu de tout ! Mais dans ce cas, quelle est l’application la plus d\u00e9rang\u00e9e et surtout quelle est l’application qui provoque la congestion ? Il vous faut en effet \u00eatre conscient d’une chose : Vous pourrez monter aussi haut que vous voudrez en d\u00e9bit certaines applications utiliseront toujours la totalit\u00e9 de la bande passante disponible<\/strong> !<\/p>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/DEBIT.gif\")
<\/p>\nAinsi un transfert FTP<\/strong> ou SMTP<\/strong> va monter aussi haut en d\u00e9bit que le permet la charge et la performance des serveurs et clients et bien s\u00fbr le lien d’interconnexion. Si vous montez en d\u00e9bit vous allez uniquement gagner sur le temps de transfert du fichier, qui va r\u00e9duire (je pr\u00e9cise, au cas o\u00f9 il y en aurait qui dormirait !<\/em>). Nous sommes dans le cas du graphe C ci-contre. Votre zone inoccup\u00e9e globale aura augment\u00e9e mais les pointes de trafic sont toujours l\u00e0 ! Une application transactionnelle qui discute en m\u00eame temps qu’un transfert de ce type pourra donc en ressentir les effets …<\/p>\n
Mais avouons tout de m\u00eame que g\u00e9n\u00e9ralement l’effet est b\u00e9n\u00e9fique ! Les transferts FTP sont plus rapides, la r\u00e9partition du trafic est plus homog\u00e8ne et tout le monde est content … sauf le directeur des achats !<\/em><\/p>\n
2.<\/span><\/strong> Mais, justement ! Tout le monde trouve \u00e7a super, et s’en donne \u00e0 coeur joie ! T\u00e9l\u00e9chargement de MP3, visio-conf\u00e9rences, pi\u00e8ces jointes de plusieurs m\u00e9ga-octets ! L’anarchie quoi ! Et quelques mois plus tard, vous \u00eates de nouveau en congestion ! Il sera donc peut-\u00eatre n\u00e9cessaire d’avoir une approche compl\u00e9mentaire \u00e0 celle de la mont\u00e9e en d\u00e9bit … Nous y viendrons plus tard !<\/p>\n
Donc, oui \u00e0 l’augmentation de d\u00e9bit, mais non \u00e0 l’embolie ! Si le lien est constamment charg\u00e9, il faut monter en d\u00e9bit, mais il faut d’abord savoir pourquoi !! Par contre, si vos liens ne pr\u00e9sentent jamais de congestion vous pouvez en d\u00e9duire que votre architecture est surdimensionn\u00e9e<\/strong> !<\/p>\n
Une bande passante variable, c’est possible ?<\/h2>\n
En effet, si l’on pouvait disposer d’un support de transmission qui soit capable de prendre en charge des pointes de trafic quand elles se pr\u00e9sentent et de descendre \u00e0 un d\u00e9bit minimal lorsque le trafic est calme, ce serait l’id\u00e9al ! On diminue ainsi fortement la zone inoccup\u00e9e ! Bien s\u00fbr cela n’a d’int\u00e9r\u00eat que si ce support est moins cher qu’un support de d\u00e9bit \u00e9gal \u00e0 la pointe de trafic ! Sinon autant mettre des hauts d\u00e9bits partout !<\/p>\n
Ce type de support existe, citons pour exemple : Frame Relay, ATM ou ADSL\/TDSL (qui est de l’ATM en fait ! Nous y reviendrons !). Attention, ce sont plus des protocoles que des supports ! Rappelez-vous le mod\u00e8le OSI, le support est au niveau 1, sa PDU est le bit ! Frame Relay et ATM ont des structures de blocs de donn\u00e9es, c’est du niveau 2, m\u00eame si ATM n\u00e9cessite un compl\u00e9ment de niveau 2 (la couche AAL).<\/p>\n
Quoiqu’il en soit le principe est le m\u00eame avec ces deux technologies (je consid\u00e8re que l’ADSL est assimil\u00e9 \u00e0 l’ATM, car en fait l’ADSL est une technique de transcodage des informations et n’a rien \u00e0 voir avec la notion de d\u00e9bit variable !). Ce mode de fonctionnement induit trois nouveaux crit\u00e8res :<\/p>\n
- \n
- le d\u00e9bit minimum<\/strong> (garanti ou non d’ailleurs) : c’est le d\u00e9bit que vous \u00eates certains d’avoir 100% du temps.<\/li>\n
- le d\u00e9bit cr\u00eate<\/strong> : c’est le d\u00e9bit maximum que vous pourrez obtenir<\/li>\n
- le burst<\/strong> : c’est la capacit\u00e9 du support \u00e0 maintenir le d\u00e9bit cr\u00eate (pendant un certain temps).<\/li>\n<\/ul>\n
Ce type de support pr\u00e9sente g\u00e9n\u00e9ralement une tarification avantageuse par rapport aux supports \u00e0 bande passante garantie car il permet aux op\u00e9rateurs de dimensionner leur backbone sur la valeur d’un d\u00e9bit moyen (quelque part entre le d\u00e9bit minimum et le d\u00e9bit cr\u00eate) d’acc\u00e8s. Cette valeur de d\u00e9bit moyen, et donc de dimensionnement du backbone, est d’ailleurs souvent un des crit\u00e8res de diff\u00e9renciation des op\u00e9rateurs et de la qualit\u00e9 de service fournie.<\/p>\n
Il est maintenant n\u00e9cessaire de bien comprendre deux choses :<\/p>\n
- \n
- ces technologies sont d\u00e9finies pour des connexions \u00e0 un backbone<\/strong>. Mettre en place du Frame Relay sur une liaison point \u00e0 point n’a pas beaucoup de sens (enfin presque … on peut s\u00e9parer les services par CVP, mais ce n’est pas le sujet ici).<\/li>\n
- le support d’acc\u00e8s au backbone doit \u00eatre capable de fournir le d\u00e9bit cr\u00eate<\/strong> ! Sinon \u00e0 quoi \u00e7a sert ! On ne pourra jamais b\u00e9n\u00e9ficier des \u00ab\u00a0bursts\u00a0\u00bb autoris\u00e9s par le backbone !<\/li>\n<\/ul>\n
Un petit sch\u00e9ma vaut mieux qu’un grand discours ! Dans l’exemple ci-dessous, deux sites (A et B) sonr raccord\u00e9s respectivement \u00e0 128 Kbps et 64 Kbps sur un lien de concentration lui-m\u00eame dimensionn\u00e9 \u00e0 128 Kbps (soit donc en th\u00e9orie sous-dimensionn\u00e9). Pour le site A ont garanti un d\u00e9bit mini de 50% du d\u00e9bit cr\u00eate (ici 128 Kbps), pour le site B le d\u00e9bit minimum garanti est de 32 kbps pour un d\u00e9bit cr\u00eate \u00e0 64 Kbps. Les graphes A et B symbolisent la r\u00e9partition du trafic dans le temps pour chaque site. Vous remarquerez que chacun d’eux d\u00e9passe all\u00e9grement le d\u00e9bit minimum par pointe de trafic. C’est les \u00ab\u00a0bursts\u00a0\u00bb.<\/p>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/BURST.gif\")
<\/p>\nLe graphe C repr\u00e9sente la somme th\u00e9orique brute des trafics des deux sites. Vous remarquez la pr\u00e9sence d’une congestion en d\u00e9but de graphe car la somme des d\u00e9bits n\u00e9cessaires d\u00e9passe les capacit\u00e9s du support. Je pr\u00e9cise (au cas o\u00f9 !<\/em>) que le fait que le trafic vert<\/strong> <\/span>soit empil\u00e9 sur le bleu<\/strong> <\/span>n’est qu’une vue de l’esprit ! Tous les paquets se m\u00e9langent bien s\u00fbr ! On pourrait ici laisser agir uniquement les buffers tel que nous l’avons d\u00e9crit pr\u00e9c\u00e9demment pour \u00ab\u00a0encaisser\u00a0\u00bb la charge passag\u00e8re ! Mais ici le traitement est plus subtil !<\/p>\n
Le graphe D symbolise l’action du m\u00e9canisme de bande passante variable sur le principe des \u00ab\u00a0bursts\u00a0\u00bb. Votre oeil exerc\u00e9 aura remarqu\u00e9 que le traitement est diff\u00e9renci\u00e9 en fonction de la provenance du trafic. La congestion sur le trafic \u00ab\u00a0vert\u00a0\u00bb est bien report\u00e9e dans le temps mais une partie est prise imm\u00e9diatement en charge au d\u00e9triment du trafic \u00ab\u00a0bleu\u00a0\u00bb. R\u00e9sultat une partie du trafic bleu est r\u00e9port\u00e9 dans le temps \u00e9galement ! Examinons cela dans le d\u00e9tail :<\/p>\n
- \n
- A ce moment T du trafic il faut acheminer 128K pour le trafic \u00ab\u00a0bleu\u00a0\u00bb et 64K pour le trafic \u00ab\u00a0vert\u00a0\u00bb sur un lien mutualis\u00e9 \u00e0 128K max ! Nous avons donc une congestion d’une valeur de 64K !<\/li>\n
- Le d\u00e9bit minimum garanti pour le trafic \u00ab\u00a0bleu\u00a0\u00bb est de 64K. Il est donc le double de celui du trafic \u00ab\u00a0vert\u00a0\u00bb qui est fix\u00e9 \u00e0 32K. Par contre la somme des d\u00e9bits minimum est de 64+32 = 96K pour un lien capable d’acheminer 128K. Il aurait \u00e9t\u00e9 dommage de limiter les deux trafics \u00e0 leur valeur mini parce qu’il y a une congestion ! Il est plus intelligent d’exploiter les 32K de surplus en autorisant chaque trafic \u00e0 d\u00e9passer l\u00e9g\u00e8rement son minimum autoris\u00e9<\/strong>.<\/li>\n
- Il s’agit de r\u00e9partir \u00ab\u00a0\u00e9quitablement\u00a0\u00bb ce d\u00e9passement autoris\u00e9 entre les deux trafics sur la base de leur rapport de d\u00e9bit minimum. Comme le d\u00e9bit minimum garanti du flux \u00ab\u00a0bleu\u00a0\u00bb est double de celui du flux \u00ab\u00a0vert\u00a0\u00bb, le flux \u00ab\u00a0bleu\u00a0\u00bb aura droit \u00e0 deux tiers du burst de 32K possible soit environ 21K suppl\u00e9mentaires, alors que le trafic vert aura droit au tiers restant soit donc 11K.<\/li>\n
- Au total sur cette zone T, le trafic \u00ab\u00a0bleu\u00a0\u00bb aura b\u00e9n\u00e9fici\u00e9 d’une bande passante de 85K (64+21) et le trafic \u00ab\u00a0vert\u00a0\u00bb d’une bande passante de 45K (32+11) ! Le surplus de trafic de chaque flux soit donc 43K pour le \u00ab\u00a0bleu\u00a0\u00bb et 19K pour le \u00ab\u00a0vert\u00a0\u00bb est report\u00e9 dans le temps par la mise en buffer !<\/li>\n<\/ul>\n
Cette d\u00e9monstration permet d’\u00e9mettre les constatations suivantes :<\/p>\n
- \n
- La m\u00e9thode de mesure du burst, de surveillance du d\u00e9bit minimum et de r\u00e9partition \u00e9galitaire des d\u00e9passements rel\u00e8ve du principe de bande passante variable du protocole (Frame Relay ou ATM). Chaque protocole utilisera son propre m\u00e9canisme et ses propres d\u00e9finitions<\/strong>, par exemple en Frame Relay<\/strong> on parlera de CIR<\/strong> pour le d\u00e9bit minimum et la gestion de \u00ab\u00a0burst<\/strong>\u00a0\u00bb sera r\u00e9alis\u00e9e sur la base d’un calcul de temps de transmission et de nombre de trame (voir de volume de donn\u00e9es mais c’est plut\u00f4t rare !). En ATM<\/strong> on parlera par contre de SCR<\/strong> pour le d\u00e9bit minimum, de PCR<\/strong> pour le d\u00e9bit cr\u00eate et de MBS<\/strong> correspondant \u00e0 un nombre de cellules pour la capacit\u00e9 du burst !<\/li>\n
- Dans tous les cas, la fonction de report du trafic dans le temps rel\u00e8ve de l’action des buffers ! Par contre il sera \u00e9galement n\u00e9cessaire de pr\u00e9voir au niveau protocolaire un accord et une m\u00e9thode pour d\u00e9cider du principe de suppression des trames en surplus en cas de d\u00e9bordement des buffers. En ATM et en Frame Relay on marque les trames (ou cellules) consid\u00e9r\u00e9es comme au-del\u00e0 du d\u00e9bit minimum. On parle de \u00ab\u00a0tag<\/strong>\u00a0\u00bb pour le marquage (bits FECN et BECN en Frame Relay par exemple).<\/li>\n
- Dans l’exemple ci-dessus vous avez pu remarquer que les flux \u00ab\u00a0bleus\u00a0\u00bb et \u00ab\u00a0verts\u00a0\u00bb b\u00e9n\u00e9ficient au global d’un d\u00e9bit sup\u00e9rieur situ\u00e9 entre leur minimum garanti et leur d\u00e9bit cr\u00eate ! On parle de d\u00e9bit moyen<\/strong>. Plus le lien mutualis\u00e9 sera surdimensionn\u00e9, plus le d\u00e9bit moyen sera \u00e9lev\u00e9 ! C’est souvent ici que la diff\u00e9rence de qualit\u00e9 de service se joue entre les op\u00e9rateurs ! Le plus gros backbone l’emporte \u00e0 ce jeu !<\/li>\n
- Pour terminer, vous avez remarqu\u00e9 que la gestion du trafic est diff\u00e9renci\u00e9e en fonction de la source. L’\u00e9quipement sur le lien mutualis\u00e9 g\u00e9re diff\u00e9remment l’allocation de bande passante selon que le trafic \u00e9tait \u00ab\u00a0bleu\u00a0\u00bb ou \u00ab\u00a0vert\u00a0\u00bb. Ceci suppose que le protocole est donc capable d’identifier le trafic<\/strong> et que l’\u00e9quipement a connaissance des param\u00e8tres appliqu\u00e9s \u00e0 chacun d’eux (notamment en terme de d\u00e9bit minimum garanti !). En Frame Relay on parlera de CVP<\/strong> (C<\/strong>ircuit V<\/strong>irtuel P<\/strong>ermanent) alors qu’en ATM<\/strong> on parlera de VC<\/strong> (V<\/strong>irtual C<\/strong>ircuit), voir de VP <\/strong>(V<\/strong>irtual P<\/strong>ath). On parle \u00e9galement de \u00ab\u00a0contrat de trafic<\/strong>\u00a0\u00bb ou encore de \u00ab\u00a0shapping<\/strong>\u00ab\u00a0.<\/li>\n<\/ul>\n
Une bande passante asym\u00e9trique, c’est vraiment mieux ?<\/h2>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/ASYMETRIE.gif\")
<\/p>\nOui ! Sans conteste, dans 90% des cas !<\/p>\n
En effet, 90% des informatiques fonctionnent de la m\u00eame fa\u00e7on … Il y a quelque part un utilisateur derri\u00e8re un \u00e9cran et un clavier (ou quelque chose qui y ressemble !<\/em>) qui entre des donn\u00e9es et attend des r\u00e9sultats sur son \u00e9cran ou son imprimante. G\u00e9n\u00e9ralement les donn\u00e9es sont envoy\u00e9es \u00e0 un serveur qui r\u00e9pond (quand il a le temps !<\/em>).<\/p>\n
Souvent les r\u00e9ponses serveurs sont plus volumineuses que les requ\u00eates clients<\/strong> (utilisateurs). Donc le trafic montant vers le serveur est plus faible que le trafic descendant vers le client<\/strong>. Si le serveur est accessible par un r\u00e9seau, il serait int\u00e9ressant, pour le site h\u00e9bergeant les clients, de disposer d’un d\u00e9bit plus important pour le trafic venant du r\u00e9seau (et donc du site serveur) que celui montant vers le r\u00e9seau (et donc vers le site serveur). Par contre pour le site serveur c’est l’inverse ! Il a besoin de livrer plus de trafic que d’en recevoir !<\/p>\n
Citons pour exemple les applications de transfert de fichiers type FTP (\u00e0 partir du moment o\u00f9 le transfert se fait d’un serveur vers un poste client, et pas entre serveurs !), les applications transactionnelles vers des bases de donn\u00e9es, la consultation de boite aux lettres (POP3 ou IMAP4), encore qu’il faille relativiser car quand on envoi une grosse pi\u00e8ce jointe le volume montant peut \u00eatre important, etc …<\/p>\n
Bien s\u00fbr ceci ne s’applique pas \u00e0 tous les types d’applications, par exemple quand il s’agit de r\u00e9plication ou de mirroring de serveurs les flux sont importants dans les deux sens ! Il en va de m\u00eame pour le trafic entre serveurs de messagerie ou les applications d’int\u00e9gration voix-donn\u00e9es ou visioconf\u00e9rence !<\/p>\n
La bande passante asym\u00e9trique \u00e9tait d\u00e9j\u00e0 disponible depuis longtemps avec des technologie comme le Frame Relay (CVP \u00e0 CIR asym\u00e9triques) ou l’ATM mais les supports \u00e0 bande passante asym\u00e9trique ont pris leur envol\u00e9e r\u00e9cemment avec l’arriv\u00e9e de l’ADSL<\/strong> ! En effet, l’ADSL (Asymetric Digital Subscriber Line) est une m\u00e9thode d’encodage des donn\u00e9es sur un support (un transcodage … rappelez-vous le cours OSI, couche Physique !) qui offre l’avantage :<\/p>\n
- \n
- d’utiliser la partie haute de la bande de fr\u00e9quence des supports cuivres<\/strong>. On transcode le signal dans une bande de fr\u00e9quence en dehors de la bande 300-3400 Hz utilis\u00e9e par la voix sur le support t\u00e9l\u00e9phonique. Ceci permet donc de transmettre des donn\u00e9es sur une ligne en m\u00eame temps qu’on parle ! Cool non ? (C’est pour \u00e7a messieurs que vos femmes acceptent de payer vos abonnements ADSL ! Elles peuvent continuer de passer des heures au t\u00e9l\u00e9phone avec leurs copines !<\/em>). Par contre il y a une contrainte de distance car \u00e0 cette fr\u00e9quence, l’affaiblissement du signal est important et au-del\u00e0 de quelques Km d’un point de r\u00e9g\u00e9n\u00e9ration il n’y a plus de signal !<\/li>\n
- de proposer un d\u00e9bit asym\u00e9trique<\/strong> ! La bande porteuse montante vers le r\u00e9seau ne peut pas encoder aussi vite que la bande descendante et donc le d\u00e9bit est moindre ! De mani\u00e8re optimale on obtient un d\u00e9bit montant (du site vers le r\u00e9seau) \u00e0 800 Kbps pour un d\u00e9bit descendant (du r\u00e9seau vers le site) \u00e0 environ 2 Mbps.<\/li>\n
- d’assurer un d\u00e9bit binaire variable<\/strong> en fonction du contrat de trafic ATM (niveau 2 impl\u00e9ment\u00e9 sur le niveau 1 ADSL) propos\u00e9 par l’op\u00e9rateur, ce qui permet \u00e0 celui-ci d’afficher plusieurs types d’acc\u00e8s ADSL en fonction des d\u00e9bits maximum propos\u00e9s. Ainsi France T\u00e9l\u00e9com, propose un acc\u00e8s Netissimo 1 \u00e0 512 Kbps en r\u00e9ception et 128 Kbps en \u00e9mission et un Netissimo 2 qui double ces valeurs, soit 1024 Kbps (1Mbps) et 256 Kbps !<\/li>\n<\/ul>\n
Par contre en dehors de la limitation de distance, qui oblige \u00e0 proc\u00e9der \u00e0 une \u00e9tude d’\u00e9ligibilit\u00e9 au service ADSL avant d’y souscrire, une autre contrainte appara\u00eet, peu sensible dans le cas de l’Internet, mais r\u00e9dhibitoire pour certaines applications : le d\u00e9lai de transit<\/strong> !<\/p>\n
En effet, l’ADSL est la technique d’encodage du signal, c’est donc du niveau 1 ! Sur le niveau 1 on place un niveau 2 (couche Liaison, rappelez-vous le mod\u00e8le OSI !). Cette couche est une couche ATM qui elle-m\u00eame n\u00e9cessite une sur-couche AAL pour v\u00e9hiculer du trafic comme IP par exemple. Or en ATM, la norme d\u00e9fini la MTU \u00e0 48 octets sur une cellule de 53 octets (une trame quoi !). Vous imaginez donc bien qu’on est oblig\u00e9 de fragmenter les paquets, ce qui induit un retard non n\u00e9gligeable dans la transmission. A ceci s’ajoute l’encha\u00eenement des \u00e9quipements de collecte du trafic qui n’arrange pas les choses.<\/p>\n
Si vous utilisez des applications qui profitent largement d’une bande passante importante (transferts de fichiers, client-serveur en mode non connect\u00e9, transactionnel en mode page) il n’y a pas de probl\u00e8me. Le gain en bande passante compense largement l’augmentation du d\u00e9lai de transit<\/strong> et au final c’est plus rapide ! Par contre si vos applications sont de type client-serveur en mode caract\u00e8re ou champ par champ, ou encore si vous utilisez des syst\u00e8mes d’\u00e9mulation comme CITRIX ou Terminal Server, les effets peuvent \u00eatre sid\u00e9rants ! Il est pr\u00e9f\u00e9rable de proc\u00e9der \u00e0 un test ! En effet, ce type d’application est r\u00e9put\u00e9 n’avoir pas besoin d’une grosse bande passante, donc elles n’utilisent pas celle mise \u00e0 disposition, et l’utilisateur ressent de plein fouet l’augmentation du d\u00e9lai de transit !<\/p>\n
Pour r\u00e9sumer :<\/strong><\/p>\n
- \n
- L’asym\u00e9trie de d\u00e9bit est un r\u00e9el avantage<\/strong>. Pour un site client on pr\u00e9f\u00e9rera une bande passante importante pour le trafic descendant du r\u00e9seau. Pour un site serveur on pr\u00e9f\u00e9rera une bande passante importante pour le trafic qui monte vers le r\u00e9seau.<\/li>\n
- La technologie de pr\u00e9dilection pour ce type d’acc\u00e8s est l’ADSL (ou Turbo DSL) mais attention : la bande passante importante est toujours descendante du r\u00e9seau, ceci est donc inadapt\u00e9 pour un site serveur<\/strong><\/li>\n
- des contraintes de distances fortes<\/strong> emp\u00eachent parfois son utilisation pour certains sites \u00ab\u00a0perdus\u00a0\u00bb<\/li>\n
- le d\u00e9lai de transit peut nuire<\/strong> \u00e0 certaines applications<\/li>\n
- Rappelons que la couche ATM fournie permet en plus d’offrir une bande passante variable<\/strong> telle qu’\u00e9tudi\u00e9 dans le paragraphe pr\u00e9c\u00e9dent.<\/li>\n<\/ul>\n
Prioriser le trafic, est-ce une bonne solution ?<\/h2>\n
Soyons clair ! De nombreux concepteurs voient l\u00e0 une m\u00e9thode id\u00e9ale pour contr\u00f4ler la congestion ! C’est faux !<\/p>\n
\n\n
\n La priorisation pour la congestion, c’est un peu comme l’aspirine pour la rage de dent ! <\/span><\/strong><\/p>\n Ca calme un peu la douleur, mais \u00e7a ne soigne pas la carie !<\/span><\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Nous l’avons vu, le cot\u00e9 nuisible et p\u00e9nible de la congestion<\/strong> est qu’elle ralentie le trafic<\/strong>, puisqu’elle oblige \u00e0 buff\u00e9riser et donc reporter la transmission. Nous avons vu que si celle-ci se prolonge il va y avoir \u00ab\u00a0over full in buffer\u00a0\u00bb ! Le r\u00e9sultat est une perte de donn\u00e9es, qui n\u00e9cessite une r\u00e9\u00e9mission par les protocoles, et donc un ralentissement de transmission du point de vue utilisateur …<\/p>\n
Si ces effets sont toujours ind\u00e9sirables, nous avons vu qu’il fallait relativiser … Pour des transferts de fichiers ou de la messagerie, l’allongement de quelques millisecondes sur le d\u00e9lai de transmission ne m\u00e9rite pas d’en faire un fromage !<\/strong> Par contre, si l’application est de type transactionnelle champ par champ ou mode caract\u00e8re (voir \u00e9mulation graphique) il est fort possible que ce ralentissement soit directement ressenti par l’utilisateur qui va vous … tomber sur le poil !<\/em><\/p>\n
Nous avons \u00e9galement vu que dans une certaine mesure vous pouviez envisager d’utiliser des supports favorisant la prise en charge de pointes de trafic ou m\u00eame envisager une mont\u00e9e en d\u00e9bit, si vous avez d’excellentes relations avec votre directeur des achats (ce qui est extr\u00eamement rare … ce sont g\u00e9n\u00e9ralement des gens irascibles et infr\u00e9quentables \ud83d\ude09<\/em>). Malheureusement le prix du Kbps n’est pas anodin et il serait dommage d’envisager une modification du support pour absorber des surcharges \u00e9pisodiques !<\/p>\n
Dans ce cas, la priorisation peut vous aider ! Le principe est simple ! En cas de congestion, et en cas de congestion SEULEMENT, les \u00e9quipements de transmission vont autoriser la transmission en priorit\u00e9 de certains flux par rapport \u00e0 d’autres<\/strong> qui seront retard\u00e9s (buff\u00e9ris\u00e9s). Vous allez donc programmer vos \u00e9quipements d’interconnexion pour qu’ils analysent le type de trafic qui leur passe sous le nez et qu’il classifie (on dit aussi marquer ou colorier) dans un niveau de priorit\u00e9 \u00e9lev\u00e9 le trafic de vos applications sensibles pour les utilisateurs (ou pour l’entreprise … quelquefois les vues sont divergentes \u00e0 ce propos !!<\/em>). Lorsqu’il y a congestion cet \u00e9quipement transmet d’abord les donn\u00e9es des flux prioritaires. Cela para\u00eet simple, le principe l’est, mais ses d\u00e9clinaisons et sa mise en \u0153uvre beaucoup moins ! Par exemple :<\/p>\n
- \n
- Combien de niveau de priorit\u00e9 sont d\u00e9finis ?<\/strong> Vous pouvez \u00eatre tent\u00e9 de d\u00e9finir plus de deux niveaux de priorit\u00e9, par exemple le tr\u00e8s prioritaire, le prioritaire, le moyennement prioritaire, le presque pas prioritaire et le pas prioritaire du tout (qu’est ce qu’on se marre, dans le r\u00e9seau !<\/em>). Tout de suite on sent le probl\u00e8me ! Il va falloir d\u00e9finir plusieurs files d’attentes en fonction de la priorit\u00e9 … Bonjour les besoins en m\u00e9moire !<\/em><\/li>\n
- Tout de suite derri\u00e8re se pose la mani\u00e8re de vider ces m\u00e9moires tampons ! Je commence \u00e0 vider le prioritaire uniquement quand j’en ai fini avec le tr\u00e8s prioritaire ? Ca para\u00eet raisonnable ! Mais si mon trafic tr\u00e8s prioritaire est constamment pr\u00e9sent ? Le moins prioritaire peut aller se coucher ? On appelle ce ph\u00e9nom\u00e8ne, la famine<\/strong> ! Le trafic moins prioritaire n’est plus achemin\u00e9, il y a un manque quelque part (pour un utilisateur par exemple). On dit \u00ab\u00a0famine\u00a0\u00bb parce que le trafic prioritaire \u00ab\u00a0mange\u00a0\u00bb toute la bande passante (Le goulu ! L’\u00e9go\u00efste !<\/em>).<\/li>\n
- Donc on essaie de mettre en place quelque chose de plus \u00ab\u00a0humanitaire<\/em>\u00ab\u00a0. On accorde au trafic le plus prioritaire une part garantie de bande passante (par exemple 50%) et \u00e0 chaque classe de trafic (niveau de priorit\u00e9) une part r\u00e9partie sur le reste. Par exemple pour trois classes de trafic on utilisera une r\u00e9partition 60-30-10 ! Ainsi m\u00eame le trafic \u00ab\u00a0bas de classe\u00a0\u00bb est s\u00fbr de pouvoir passer … un peu ! C’est l’id\u00e9al n’est ce pas ?<\/li>\n
- OK ! C’est beau ! Mais si je n’ai pas de trafic prioritaire mais que la charge engendr\u00e9e par le trafic non prioritaire g\u00e9n\u00e9re une congestion<\/strong> ? Je sous-emploie 50% de ma bande passante (les 50% r\u00e9serv\u00e9s au trafic prioritaire) ? Bonjour le gaspillage ! Donc il faut que je fasse de la r\u00e9partition de bande passante dynamique ! Tout ce qui n’est pas utilis\u00e9 par une classe peut l’\u00eatre par une autre ! OK … On commence \u00e0 approcher de la perfection …<\/li>\n
- Mais il y a encore d’autres aspects complexes dans la prioritisation comme la mani\u00e8re dont on doit s’y prendre pour \u00e9viter l’engorgement des buffers de chaque classe ! Dois-je attendre d’\u00eatre \u00ab\u00a0full\u00a0\u00bb ou est-ce que je commence \u00e0 all\u00e9ger le trafic avant l’engorgement en supprimant des paquets ? Dois-je plut\u00f4t supprimer des gros ou des petits paquets ? Etc, etc. Arr\u00eatons-nous l\u00e0 !<\/li>\n<\/ul>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/PRIO.gif\")
<\/p>\nVous l’aurez compris, \u00e7a para\u00eet simple, mais c’est en fait loin de l’\u00eatre ! Les algorithmes sont extr\u00eamement complexes et les ressources (CPU, m\u00e9moires) sont importantes ! Pour r\u00e9sumer :<\/p>\n
- \n
- La priorisation n’est pas une r\u00e9ponse \u00e0 une charge massive d’un r\u00e9seau ou d’un lien<\/strong>. Seul l’upgrade en d\u00e9bit est la r\u00e9ponse dans ce cas !<\/li>\n
- La priorisation est une solution complexe \u00e0 mettre en oeuvre<\/strong> et qui ne doit agir que pour maintenir une qualit\u00e9 de service la plus constante possible pour des applications sensibles en diminuant l’effet n\u00e9faste des congestions passag\u00e8res (pointes de trafic) qui ne justifient pas d’un upgrade.<\/li>\n
- Dans certains cas, la priorisation est une arme absolue pour mettre un frein \u00e0 la fr\u00e9n\u00e9sie des utilisateurs gourmands en bande passante<\/strong> ! J’ai le cas d’un client qui bridait ainsi la bande passante Internet par utilisateur \u00e0 10 Kbps (adieu le MP3 !). Il \u00e9tait ainsi s\u00fbr de garder la bande passante n\u00e9cessaire pour son Oracle !<\/li>\n
- Les \u00e9quipementiers impl\u00e9mentent tous des m\u00e9canismes de priorisation, propri\u00e9taires ou non, sur leurs mat\u00e9riels. Les fonctions offertes sont plus ou moins \u00e9labor\u00e9es selon les cas.<\/li>\n<\/ul>\n
Enfin je voudrais attirer votre attention sur le probl\u00e8me de correspondance entre les politiques de priorisation de niveau 3 et la gestion de bande passante variable telle que nous venons de la voir. Je ne peux pas d\u00e9velopper ici ce probl\u00e8me, mais essayez d’imaginer le probl\u00e8me suivant : Si je buff\u00e9rise une trame Frame Relay par exemple, comment savoir si celle-ci ne contient pas un paquet prioritaire ? Pire, je pourrais m\u00eame supprimer cette trame parce que mes buffers sont pleins et que le contrat de trafic est d\u00e9pass\u00e9 ! Des paquets prioritaires plac\u00e9s dans des trames \u00e9mises dans la zone de \u00ab\u00a0burst\u00a0\u00bb, et donc candidates \u00e0 la suppression ou au rejet, sont donc susceptibles de ne pas \u00eatre achemin\u00e9s … L’id\u00e9al serait que je place mes paquets prioritaires dans des trames comprises dans la zone de bande passante garantie … Mais pour que la priorisation soit activ\u00e9e il faut que le support soit consid\u00e9r\u00e9 en congestion ! Si je d\u00e9fini le niveau de congestion \u00e0 la valeur du d\u00e9bit garanti au lieu du d\u00e9bit \u00ab\u00a0burst\u00a0\u00bb je me prive de la possibilit\u00e9 de \u00ab\u00a0burster\u00a0\u00bb !<\/p>\n
Et oui ! Pas facile, tout \u00e7a …<\/p>\n
Et la gestion de flux ? Est-ce la r\u00e9ponse universelle ?<\/h2>\n
Tout d’abord pr\u00e9cisons les choses ! La gestion de flux en soit est une notion tr\u00e8s vague et tr\u00e8s large ! Les m\u00e9canismes de \u00ab\u00a0bufferisation\u00a0\u00bb ou de gestion de bandes passantes variables tels que nous venons de les \u00e9tudier sont eux-m\u00eames des m\u00e9canismes de gestion de flux !<\/p>\n
La gestion de flux<\/strong>, appel\u00e9e aussi contr\u00f4le de flux<\/strong>, dont je veux vous entretenir ici, rel\u00e8ve plus de m\u00e9canismes protocolaires permettant \u00e0 un \u00e9quipement surcharg\u00e9 de demander \u00e0 une source de trafic de ralentir ou stopper ses \u00e9missions. Dans ces conditions, il est important de comprendre une chose :<\/p>\n
\n\n
\n Le contr\u00f4le de flux n’est pas un moyen d’\u00e9viter la congestion, il permet de g\u00e9rer le probl\u00e8me du risque de perte de donn\u00e9es quand il y a une congestion grave (qui dure !).
\n<\/span><\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nLe contr\u00f4le de flux sera activ\u00e9 par un \u00e9quipement lorsque ses buffers atteindront un certain niveau de remplissage (disons 80%). Afin d’\u00e9viter que les nouvelles donn\u00e9es viennent \u00e9craser celles d\u00e9j\u00e0 en attente dans les registres m\u00e9moires, ce qui revient \u00e0 perdre des donn\u00e9es, l’\u00e9quipement va activer diff\u00e9rents protocoles pour calmer les ardeurs des \u00e9metteurs !<\/p>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/CF1.gif\")
<\/p>\nLors du cours OSI nous avons abord\u00e9 ces notions et je vous ai notamment fait remarquer que la gestion de flux pouvait \u00eatre mise en \u0153uvre \u00e0 plusieurs niveaux OSI :<\/p>\n
- \n
- au niveau 2<\/strong>, couche liaison de donn\u00e9es<\/strong>, cette gestion s’applique sur tout le trafic \u00e9chang\u00e9 entre deux \u00e9quipements directement connect\u00e9s \u00e0 travers un support physique. Le protocole de niveau 2 (HDLC, PPP, Frame Relay, etc.) offre des m\u00e9canismes qui permettent de ralentir ou stopper l’\u00e9mission des trames par l’\u00e9metteur lorsque le r\u00e9cepteur est surcharg\u00e9. A ce niveau le contr\u00f4le s’applique donc uniform\u00e9ment pour l’ensemble du trafic de niveau 3<\/strong> v\u00e9hicul\u00e9 par les trames de niveau 2. Il n’est pas possible \u00e0 ce niveau de ralentir telle ou telle station qui \u00ab\u00a0s’emballe\u00a0\u00bb ! Le probl\u00e8me est ici que si le r\u00e9cepteur demande \u00e0 l’\u00e9metteur de stopper son \u00e9mission, l’\u00e9metteur continue de recevoir le trafic sur sa propre entr\u00e9e ! Il risque de passer \u00e9galement en congestion et devra demander \u00e0 son propre \u00e9metteur de stopper \u00e9galement sa transmission. On remontera ainsi petit \u00e0 petit la cha\u00eene jusqu’au point source de l’engorgement … Nous avons \u00e0 faire \u00e0 une gestion de flux de proche en proche <\/strong>! Mais, en attendant, on aura bloqu\u00e9 le trafic de tous les sites utilisant le lien alors que certains \u00e9mettaient \u00ab\u00a0raisonnablement\u00a0\u00bb ! A noter, qu’en Frame Relay l’avantage est qu’on identifie pr\u00e9cis\u00e9ment les sites \u00e9metteurs par le CVP attribu\u00e9. La gestion de flux est donc moins totale ! Mais en Frame Relay le principe n’est pas de bloquer l’\u00e9metteur mais de supprimer les trames en trop !<\/li>\n
- au niveau 3<\/strong>, couche r\u00e9seau<\/strong>, cette gestion s’applique \u00e0 une communication de niveau 3 donn\u00e9e et non plus \u00e0 l’ensemble du trafic entre deux \u00e9quipements au niveau 2<\/strong>. Le protocole de niveau 3 est donc capable d’identifier le circuit (X25) ou l’adresse de l’\u00e9metteur (IP) pour appliquer un contr\u00f4le de flux au trafic de ce seul \u00e9metteur. Le contr\u00f4le de flux est donc \u00ab\u00a0plus fin\u00a0\u00bb mais n\u00e9cessite une gestion plus complexe, plus gourmande en ressource. On pourrait penser, en regard de cette explication, que le contr\u00f4le de flux de niveau 3 est donc un contr\u00f4le de bout en bout. En fait ce n’est pas forc\u00e9ment le cas, car : l’\u00e9quipement en congestion qui \u00e9met les ordres d’arr\u00eat \u00e0 l’\u00e9metteur n’est pas forc\u00e9ment la station de destination finale du trafic, ce peut \u00eatre un commutateur ou routeur interm\u00e9diaire.<\/li>\n
- le contr\u00f4le peut \u00e9galement s’appliquer de proche en proche<\/strong> comme c’est le cas en X25. C’est \u00e0 dire que le commutateur qui est submerg\u00e9 informe le commutateur pr\u00e9c\u00e9dent qu’il ne prend plus en charge le trafic lequel informera le pr\u00e9c\u00e9dent, ainsi de suite jusqu’\u00e0 la station \u00e9mettrice. L’information ne remonte donc pas directement \u00e0 la source !<\/li>\n
- au niveau 4,<\/strong> couche transport<\/strong>, le contr\u00f4le s’applique de processus \u00e0 processus<\/strong>, et ne nous concerne pas sur un plan r\u00e9seau. Ainsi, par exemple, un transfert FTP sera r\u00e9gul\u00e9 alors qu’un transfert HTTP ne le sera pas m\u00eame si ces transferts ont lieu simultan\u00e9ment entre les deux m\u00eames machines. Le contr\u00f4le ici est bien de bout en bout par contre dans tous les cas.<\/li>\n
- au niveau 5<\/strong>, couche Session<\/strong>, le contr\u00f4le de flux s’applique \u00e9galement pour des processus ou des travaux identifi\u00e9s, mais ceci rel\u00e8ve de l’informatique plus que du r\u00e9seau … Laissons tomber !<\/em><\/li>\n<\/ul>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/CF2.gif\")
<\/p>\nAu final, \u00e0 quel niveau le contr\u00f4le de flux est-il donc le plus adapter ? En v\u00e9rit\u00e9 : Aucun et Tous ! Comme nous venons de le voir, \u00e0 chaque niveau son utilit\u00e9 :<\/p>\n
- \n
- Le contr\u00f4le de flux de niveau 2<\/strong> pourra r\u00e9gler des probl\u00e8mes de congestion du lien<\/strong> et \u00e9viter ainsi de d\u00e9passer des seuils de \u00ab\u00a0bursts\u00a0\u00bb par exemple qui auraient pour effet d’amener \u00e0 de la perte de trames.<\/li>\n
- Le contr\u00f4le de flux de niveau 3<\/strong> r\u00e9glera les probl\u00e8mes de congestion pour respecter des contrats de trafic de r\u00e9partition d’utilisation de la bande passante par communication de niveau 3<\/strong>.<\/li>\n
- Le contr\u00f4le de flux de niveau 4<\/strong> pourra veiller \u00e0 ne pas d\u00e9passer les capacit\u00e9s de buff\u00e9risation des stations destinataires<\/strong> en informant les \u00e9metteurs directement d’une charge pour un process donn\u00e9.<\/li>\n<\/ul>\n
En r\u00e9sum\u00e9 :<\/p>\n
- \n
- Le contr\u00f4le de flux est la r\u00e9ponse obligatoire \u00e0 un service de transfert de donn\u00e9es offrant un minimum de qualit\u00e9 de service<\/strong>. Il permet d’anticiper le d\u00e9passement de capacit\u00e9 des buffers des \u00e9quipements de la cha\u00eene de donn\u00e9es avant d’arriver au niveau de pertes ou rejet de donn\u00e9es.<\/li>\n
- Il existe du contr\u00f4le de flux pour les principaux niveaux OSI<\/strong> (2, 3 et 4). Chacun contribue \u00e0 diminuer le risque de pertes de donn\u00e9es avec une port\u00e9e diff\u00e9rente.<\/li>\n
- Le contr\u00f4le de flux n’est pas la r\u00e9ponse \u00e0 une congestion<\/strong> ! Il s’active au remplissage des buffers ! La congestion est donc d\u00e9j\u00e0 pr\u00e9sente ! Mais il y a risque de d\u00e9passement du contrat de trafic et d’\u00e9crasement des donn\u00e9es dans les buffers, voir quelquefois de \u00ab\u00a0plantage\u00a0\u00bb complet des \u00e9quipements !<\/li>\n<\/ul>\n
Enfin, il existe de nombreux m\u00e9canismes, ou principes, de contr\u00f4le de flux, on parle de contr\u00f4le par cr\u00e9dit ou par fen\u00eatre ou encore par anticipation, tout cela \u00e9tant le m\u00eame chose, on parle \u00e9galement de contr\u00f4le de proche en proche ou de bout en bout, de mode caract\u00e8re (Xon\/Xoff), ou par fil (105\/108), bref ! Ce n’est pas le but de ce paragraphe ou ici nous \u00e9tudions l’utilit\u00e9 d’un contr\u00f4le de flux dans le cadre d’une congestion.<\/p>\n
Conclusion du chapitre<\/h2>\n
Un tr\u00e8s, tr\u00e8s long chapitre que j’esp\u00e8re, vous n’avez pas trouv\u00e9 trop ennuyeux ! Mais il me semblait important d’aborder cette notion de congestion et de contr\u00f4le de congestion qui est en fait le r\u00e9sultat direct d’une mutualisation des ressources r\u00e9seaux et donc une probl\u00e9matique fondamentale \u00e0 aborder lors de la constitution d’un backbone mutuel !<\/p>\n
En conclusion, retenez ceci :<\/p>\n
- \n
- La congestion est un r\u00e9sultat normal \u00e0 la mutualisation des ressources<\/strong>.<\/li>\n
- On ne doit pas chercher \u00e0 la supprimer compl\u00e8tement car elle existera toujours par pointe de trafic.<\/li>\n
- Il s’agit de faire la diff\u00e9rence avec un probl\u00e8me de charge global<\/strong> qui occasionne une surcharge constante des liens
- Il existe du contr\u00f4le de flux pour les principaux niveaux OSI<\/strong> (2, 3 et 4). Chacun contribue \u00e0 diminuer le risque de pertes de donn\u00e9es avec une port\u00e9e diff\u00e9rente.<\/li>\n
- Le contr\u00f4le de flux de niveau 3<\/strong> r\u00e9glera les probl\u00e8mes de congestion pour respecter des contrats de trafic de r\u00e9partition d’utilisation de la bande passante par communication de niveau 3<\/strong>.<\/li>\n
- au niveau 3<\/strong>, couche r\u00e9seau<\/strong>, cette gestion s’applique \u00e0 une communication de niveau 3 donn\u00e9e et non plus \u00e0 l’ensemble du trafic entre deux \u00e9quipements au niveau 2<\/strong>. Le protocole de niveau 3 est donc capable d’identifier le circuit (X25) ou l’adresse de l’\u00e9metteur (IP) pour appliquer un contr\u00f4le de flux au trafic de ce seul \u00e9metteur. Le contr\u00f4le de flux est donc \u00ab\u00a0plus fin\u00a0\u00bb mais n\u00e9cessite une gestion plus complexe, plus gourmande en ressource. On pourrait penser, en regard de cette explication, que le contr\u00f4le de flux de niveau 3 est donc un contr\u00f4le de bout en bout. En fait ce n’est pas forc\u00e9ment le cas, car : l’\u00e9quipement en congestion qui \u00e9met les ordres d’arr\u00eat \u00e0 l’\u00e9metteur n’est pas forc\u00e9ment la station de destination finale du trafic, ce peut \u00eatre un commutateur ou routeur interm\u00e9diaire.<\/li>\n
- La priorisation est une solution complexe \u00e0 mettre en oeuvre<\/strong> et qui ne doit agir que pour maintenir une qualit\u00e9 de service la plus constante possible pour des applications sensibles en diminuant l’effet n\u00e9faste des congestions passag\u00e8res (pointes de trafic) qui ne justifient pas d’un upgrade.<\/li>\n
- Tout de suite derri\u00e8re se pose la mani\u00e8re de vider ces m\u00e9moires tampons ! Je commence \u00e0 vider le prioritaire uniquement quand j’en ai fini avec le tr\u00e8s prioritaire ? Ca para\u00eet raisonnable ! Mais si mon trafic tr\u00e8s prioritaire est constamment pr\u00e9sent ? Le moins prioritaire peut aller se coucher ? On appelle ce ph\u00e9nom\u00e8ne, la famine<\/strong> ! Le trafic moins prioritaire n’est plus achemin\u00e9, il y a un manque quelque part (pour un utilisateur par exemple). On dit \u00ab\u00a0famine\u00a0\u00bb parce que le trafic prioritaire \u00ab\u00a0mange\u00a0\u00bb toute la bande passante (Le goulu ! L’\u00e9go\u00efste !<\/em>).<\/li>\n
- La technologie de pr\u00e9dilection pour ce type d’acc\u00e8s est l’ADSL (ou Turbo DSL) mais attention : la bande passante importante est toujours descendante du r\u00e9seau, ceci est donc inadapt\u00e9 pour un site serveur<\/strong><\/li>\n
- de proposer un d\u00e9bit asym\u00e9trique<\/strong> ! La bande porteuse montante vers le r\u00e9seau ne peut pas encoder aussi vite que la bande descendante et donc le d\u00e9bit est moindre ! De mani\u00e8re optimale on obtient un d\u00e9bit montant (du site vers le r\u00e9seau) \u00e0 800 Kbps pour un d\u00e9bit descendant (du r\u00e9seau vers le site) \u00e0 environ 2 Mbps.<\/li>\n
- Dans tous les cas, la fonction de report du trafic dans le temps rel\u00e8ve de l’action des buffers ! Par contre il sera \u00e9galement n\u00e9cessaire de pr\u00e9voir au niveau protocolaire un accord et une m\u00e9thode pour d\u00e9cider du principe de suppression des trames en surplus en cas de d\u00e9bordement des buffers. En ATM et en Frame Relay on marque les trames (ou cellules) consid\u00e9r\u00e9es comme au-del\u00e0 du d\u00e9bit minimum. On parle de \u00ab\u00a0tag<\/strong>\u00a0\u00bb pour le marquage (bits FECN et BECN en Frame Relay par exemple).<\/li>\n
- le support d’acc\u00e8s au backbone doit \u00eatre capable de fournir le d\u00e9bit cr\u00eate<\/strong> ! Sinon \u00e0 quoi \u00e7a sert ! On ne pourra jamais b\u00e9n\u00e9ficier des \u00ab\u00a0bursts\u00a0\u00bb autoris\u00e9s par le backbone !<\/li>\n<\/ul>\n
- le d\u00e9bit cr\u00eate<\/strong> : c’est le d\u00e9bit maximum que vous pourrez obtenir<\/li>\n
- soit augmenter la capacit\u00e9 de traitement<\/strong> de l’\u00e9quipement en congestion (\u00e7a va moins plaire au directeur des achats !)<\/li>\n<\/ul>\n
- augmenter le d\u00e9bit<\/strong> : tr\u00e8s facile mais pas vraiment du go\u00fbt du directeur des achats ! D’ailleurs est-ce que cela sera efficace longtemps ?<\/li>\n
- on peut \u00e9galement deviner que si votre capacit\u00e9 de traitement est sup\u00e9rieur, vous vous retournez plus vite pour passer vos ballons. Il est alors possible que le joueur \u00e0 qui vous passez le ballon soit \u00e9galement d\u00e9bord\u00e9. Vos ballons vont tomber, vous \u00eates confront\u00e9 \u00e0 une congestion en sortie<\/strong> ! La capacit\u00e9 de traitement est sup\u00e9rieure au d\u00e9bit de sortie<\/strong> ! Il est int\u00e9ressant de remarquer que plus vous \u00eates performant, plus vous risquez d’\u00eatre en congestion en sortie !<\/li>\n<\/ul>\n