Les comportements pathologiques de RLC

RLC [87] a ´et´e introduit par Lorenzo Vicisano et al. en 1998. RLC est un protocole de contrˆole de congestion multipoint `a couches cumulatives et orient´e r´ecepteur. Cependant, `a la diff´erence de RLM, RLC a ´et´e propos´e pour l’audio, la vid´eo et le transfert de fichiers.

3.1.3.1 Rappels sur RLC

Une source RLC encode en couches cumulatives les donn´ees et envoie chaque couche dans un groupe multipoint diff´erent. Le d´ebit de chaque couche est distribu´e de mani`ere exponen-tielle. Le m´ecanisme de d´ecouverte de la bande passante de RLC est bas´e sur la g´en´eration p´eriodique, par la source, de rafales de paquets qui sont utilis´ees pour la d´ecouverte de la bande passante au niveau de chaque r´ecepteur. La source double son d´ebit sur une p´eriode de temps courte et fixe. Cette p´eriode d’augmentation du d´ebit est imm´ediatement suivie d’une p´eriode silencieuse, de telle sorte que, en moyenne, le d´ebit est constant. Le but de ces rafales de pa-quets p´eriodiques est de simuler l’ajout d’une couche pour une courte p´eriode de temps. Si la file d’attente du goulot d’´etranglement d´eborde avec cette rafale, il n’y a pas assez de bande passante disponible pour ajouter cette nouvelle couche ; dans le cas contraire, le r´ecepteur peut ajouter une nouvelle couche. L’avantage mis en avant par les auteurs de RLC de ce m´ecanisme de d´ecouverte de la bande passante bas´e sur des rafales p´eriodiques, par rapport `a un m´eca-nisme de d´ecouverte de la bande passante bas´e sur des join-experiments comme pour RLM est que les rafales produisent moins de congestion dans le r´eseau que les join-experiments. En effet, comme la dur´ee d’une rafale est courte et de taille fixe, la congestion induite par cette rafale, s’il n’y a pas assez de bande passante pour ajouter une nouvelle couche, sera courte et de taille fixe ; `a l’inverse, la congestion induite par un join-experiment d´epend du temps que le r´ecepteur va mettre `a d´ecouvrir qu’il y a congestion et du temps qu’il va mettre `a quitter cette couche exp´erimentale. On va voir, au^x3.1.3.2, que le m´ecanisme de d´ecouverte de la bande passante bas´e sur des rafales p´eriodiques ne fonctionne pas.

RLC poss`ede ´egalement un m´ecanisme de synchronisation des abonnements des r´ecepteurs aux couches bas´e sur des points de synchronisation – un bit sp´ecial dans un paquet de donn´ees.

Il y a sur chaque couche des points de synchronisation espac´es proportionnellement `a la bande passante de la couche. Ces points sont plac´es `a la fin d’une rafale et un r´ecepteur ne peut ajouter une couche que lorsqu’il re¸coit un point de synchronisation. Ils permettent de synchroniser les abonnements aux couches et d’´eviter ainsi des sous utilisations de la bande passante ou des divergences de comportement dues `a des r´ecepteurs abonn´es `a des couches diff´erentes mais qui partagent le mˆeme goulot d’´etranglement.

Le m´ecanisme de d´ecouverte de la bande passante au niveau d’un r´ecepteur est le suivant : – un r´ecepteur ajoute une couche lorsqu’il re¸coit un point de synchronisation et qu’il n’a

3.1. COMPORTEMENTS PATHOLOGIQUES DE RLM ET RLC 41 pas d´etect´e de pertes durant la rafale pr´ec´edent ce point de synchronisation ;

– un r´ecepteur quitte une couche d´es qu’il d´etecte une perte. Cependant, un r´ecepteur ne peut quitter plus d’une couche par deaf period. Une deaf period est une p´eriode de taille fixe qui sert `a ´eviter les d´esabonnements de couches en cascade. Elle ne peut pas ˆetre ajust´ee dynamiquement durant la session.

D´es qu’un r´ecepteur d´etecte une perte, il quitte une couche, avec la contrainte d’une couche maximum par deaf period ; comme les couches sont distribu´ees de mani`ere exponentielle, le r´ecepteur va diminuer son d´ebit de mani`ere multiplicative en cas de pertes, `a la mani`ere de TCP.

C’est de l`a que vient la d´enomination TCP-like de RLC. Par contre, RLC ´etant ind´ependant du RTT il ne peut pas ˆetre TCP-friendly.

3.1.3.2 Comportements pathologiques de RLC

On va r´esumer dans ce paragraphe nos r´esultats ; les d´etails peuvent ˆetre trouv´es en an-nexe A.4. On a trouv´e trois m´ecanismes qui conduisent `a des comportements pathologiques de RLC :

– le m´ecanisme de d´ecouverte de la bande passante, bas´e sur la g´en´eration de rafales p´e-riodiques de paquets, ne fonctionne pas. En effet, pour fonctionner, ce m´ecanisme devrait simuler l’ajout d’une couche pendant une p´eriode suffisamment longue pour qu’il y ait des pertes au niveau du goulot d’´etranglement, s’il n’y avait pas assez de bande passante pour ajouter cette nouvelle couche. Or les rafales sont p´eriodiques et de taille fixe. En pra-tique, ces rafales ne font jamais d´eborder le goulot d’´etranglement. Par cons´equent, les r´ecepteurs ne d´ecouvrent pas la bonne bande passante disponible et ajoutent une couche alors qu’il n’y a pas assez de bande passante. Cette couche va cr´eer de la congestion dans le r´eseau et le r´ecepteur va quitter cette couche. Cependant, comme les rafales sont p´e-riodiques, ce ph´enom`ene va se reproduire continuellement. En outre, il est tr`es difficile d’am´eliorer ce m´ecanisme de d´ecouverte de la bande passante. En effet, le seul moyen se-rait d’avoir un m´ecanisme qui permette de d´ecouvrir la dur´ee n´ecessaire des rafales pour faire d´eborder le goulot d’´etranglement – en supposant que la source puisse effectivement modifier la dur´ee des rafales –, ce qui reviendrait `a avoir un m´ecanisme de d´ecouverte de la bande passante suppl´ementaire.

– la distribution des points de synchronisation dans RLC peut s´erieusement ralentir la vi-tesse de convergence des r´ecepteurs. En effet, les points de synchronisation `a la couche

i + 1

sont un sous ensemble des points de synchronisation `a la couche

i

. Par cons´equent, p´eriodiquement de 2 jusqu’`a

n

^{(s’il y a}

n

couches) points de synchronisation seront syn-chronis´es ; c’est-`a-dire que l’abonnement `a 2 jusqu’`a

n

couches (en fonction du nombre

de points de synchronisation synchronis´es) sera possible au mˆeme moment. Cependant, s’il y a

i

points de synchronisation synchronis´es et qu’il y a assez de bande passante pour

i

^,

1

couches mais pas pour

i

, alors la rafale de la couche

i

va produire des pertes. Tous les r´ecepteurs en aval du mˆeme goulot d’´etranglement vont d´eduire qu’ils ne peuvent pas ajouter une couche sup´erieure, quelle que soit cette couche. Ce probl`eme est difficile `a corriger car il implique de modifier la distribution des points de synchronisation. Mˆeme en d´ecalant l´eg`erement les points de synchronisation, le probl`eme persiste puisqu’un r´ecep-teur ne peut ajouter une couche que s’il n’a pas d´etect´e de congestion depuis la derni`ere rafale pr´ec´edent ce point de synchronisation.

– le comportement TCP-like de RLC est dˆu, comme on l’a vu, `a la distribution exponentielle des couches. Cependant, comme RLC est ind´ependant du RTT, il obtient une tr`es faible fraction de la bande passante disponible lorsqu’il partage le goulot d’´etranglement avec des connexions TCP ayant un petit RTT. L`a encore, le probl`eme est difficile `a corriger.

Une solution serait d’avoir une estimation du RTT. Mais premi`erement, la notion de RTT est mal d´efinie pour la transmission multipoint ; deuxi`emement, ´etant donn´e que RLC est orient´e r´ecepteur (la source ne re¸coit pas de feedback des r´ecepteurs), il est impossible pour la source (ou le r´ecepteur) d’avoir une estimation du RTT.

On a identifi´e pour RLC plusieurs comportements pathologiques. Comme pour RLM, un m´ecanisme efficace de d´ecouverte de la bande passante pourrait r´esoudre tous les probl`emes – sauf celui des points de synchronisation.

3.1.4 Conclusion

L’´etude des comportements pathologiques de RLM et RLC nous a permis de mettre en

´evidence plusieurs r´esultats fondamentaux. Il ´etait couramment admis que RLM et RLC souf-fraient de quelques faiblesses. Cependant, ces protocoles ´etaient suppos´es pouvoir, au moins temporairement, offrir un service de contrˆole de congestion pour la transmission multipoint.

On a montr´e qu’en fait ces deux protocoles souffraient de probl`emes fondamentaux qui ren-daient leur d´eploiement irr´ealiste. On a vu, de plus, que le probl`eme majeur commun aux deux protocoles ´etait un m´ecanisme de d´ecouverte de la bande passante qui ne remplit pas sa tˆache.

Cependant, on ne peut pas corriger les comportements pathologiques des m´ecanismes de d´ecou-verte de la bande passante par un simple ajustement de param`etres. De plus, dans le contexte actuel de l’internet, il est difficile d’am´eliorer significativement ces m´ecanismes de d´ecouverte de la bande passante. Plutˆot que de se cantonner `a essayer d’am´eliorer de mani`ere empirique ces m´ecanismes de d´ecouverte de la bande passante, on a d´ecid´e de s’interroger sur la raison profonde de la difficult´e de cr´eer des protocoles de contrˆole de congestion dans le contexte ac-tuel de l’internet et, en particulier, sur la possibilit´e d’ajouter des m´ecanismes dans l’internet –

3.2. LE PARADIGME FAIR SCHEDULER 43

Dans le document Multicast congestion control for best effort networks (Page 40-43)