Critiques et travaux futurs

Nous avons montr´e `a l’aide de la topologie similaire `a celle d’un FAI que les r´eseaux anarchiques sont d´ependants des files d’attente Fair-Drop, y compris dans les routeurs de coeur de r´eseau. ´Etant donn´e qu’un traitement et des ´etats pour chacun des flots n’est pas possible sur les routeur de coeurs, une alternative doit ˆetre trouv´ee `a Fair-Drop sur ces derniers<sup>16</sup>. Une solution serait d’avoir un m´ecanisme de minimisation du d´ebit semblable `aTetrys min mais qui fonctionnerait ´egalement avec DropTail. Puisque l’existence mˆeme d’un tel m´ecanisme n’est pas triviale, nous proposons que les files d’attentes `a pertes ´equitables par interfaces d’entr´ees plutˆot que par flot. La complexit´e de cette derni`ere est n´egligeable et son impl´ementation sur des routeurs `a haut d´ebit serait donc possible. Le trafic obtenu avec cette file d’attente n’est pas n´ecessairement de typemax-min fair, et ses propri´et´es sont `a ´etudier pour des topologies de tailles r´ealistes.

Un des avantages serait par exemple le fait que le taux de perte `a appliquer peut ˆetre d´eriv´e du contrˆole d’acc`es. L’op´erateur pourrait adapter librement la r´epartition du trafic afin de privil´egier l’efficacit´e plutˆot que l’´equit´e.

Nous avons montr´e que les performances de Tetrys surpassent celles de TCP pour des files d’attente de faible capacit´e mais n´eanmoins sup´erieures `a 8 paquets. En dessous de cette valeur, l’impl´ementation de Fair-Drop tend `a perdre des paquets par d´epassement de buffer plutˆot que de mani`ere ´equitable (e.g.se comporte comme un file d’attente de type Drop-Tail). Il faut donc repenser l’impl´ementation de Fair-Drop de mani`ere `a ce que les paquets des diff´erents flots demeurent ´equitablement jet´es malgr´e des files d’attente de capacit´e arbitrairement petite. Bien que d´egrad´es, nous pensons que les r´esultats de Tetrys min seront meilleurs que ceux que nous avons pu relever.

De mˆeme, afin de palier aux effets de synchronisation des flots, nous avons introduit un temps d’attente al´eatoire `a l’´emission de chaque paquet. En consid´erant une ´echelle de temps assez courte, le d´ebit obtenu par un flot lorsqu’il partage un goulot d’´etranglement tend `a ˆetre variable. Le d´ebit pr´ealablement estim´e est donc biais´e ce qui p´enalise l’ef-ficacit´e de Tetrys en particulier pour un faible RTT. De la mˆeme mani`ere, les pertes appliqu´ees par Fair-Drop sont uniformes. Les appliquer de fa¸con r´eguli`ere (`a la fa¸con d’un tourniquet) permettrait d’obtenir un d´ebit beaucoup moins variable `a court terme

16. Cependant, il a r´ecemment ´et´e montr´e par Lawrence Roberts que mˆeme les routeurs de coeur pourraient g´erer un grand nombre d’´etat `a la vol´ee [114]

et donc de p´enaliser moindrement l’estimation du d´ebit et du nombre de paquets man-quants.

Bien que l’´evaluation des applications temps r´eel nous permette de dire qu’il est possible de supporter ces derni`eres dans un r´eseau anarchique, elle reste sommaire et n’apporte pas d’information sur les conditions rencontr´ees par les flots et particuli`erement sur la distribution des pertes. En effet, plus les pertes sont group´ees, plus il faut que Tetrys g´en`ere de la redondance afin de les reconstruire dans le d´elai imparti par l’application et moins les r´eseaux anarchiques sont efficaces. Il semblerait malgr´e tout qu’avec Fair-Drop ou RED, les pertes soient uniform´ement distribu´ees.

Conclusion et travaux futurs

118

R´ esum´ e des contributions et perspectives

Ce chapitre r´esume les principales contributions de cette th`ese avant de pr´esenter les perspectives de travaux jug´ees les plus pertinentes.

8.1 Conclusion g´ en´ erale

Cette th`ese pr´esente un code `a effacement appel´e Tetrys. Nous avons mis en avant ses propri´et´es innovantes dans des contextes aussi vari´es que les applications temps r´eel ; les DTN et la gestion de la mobilit´e. Nous avons montr´e qu’il permet de g´en´erer des symboles de redondance `a la vol´ee, sans rendement et qu’il tol`ere des corps finis de petite taille (GF(4)). De plus, il peut ˆetre consid´er´e comme un code fortement MDS (quasiment) et permet une fiabilit´e totale. Sa mod´elisation `a permis de d´eriver son temps de d´ecodage et de montrer que sa complexit´e en temps et en espace est abordable. La combinaison de ses diverses propri´et´es en font en code polyvalent avec une large palette d’application possible.

Nous nous somme concentr´es sur son utilisation comme m´ecanisme de fiabilit´e de bout en bout. Dans ce contexte, sa configuration ne d´epend que du taux de redondance ce qui la rend bien plus robuste que celle des codes bloc. Finalement, nous avons propos´e une heuristique pour la configuration de Tetrys. Elle permet de minimiser le taux de redondance utilis´e tout en satisfaisant les besoins des applications en termes de d´elai de reconstruction et de fiabilit´e.

Compar´e `a des codes en bloc, Tetrys permet d’am´eliorer la qualit´e d’une vid´eo transmise sur un canal `a effacement. Cependant cette application ne tire par profit de la fiabilit´e

119

totale de Tetrys et lorsqu’une trame est incompl`ete elle est (au mieux) affich´ee avec une erreur qui se r´epercutera sur les trames suivantes. Nous avons donc propos´e d’adapter les codecs vid´eo de fa¸con `a ce qu’ils r´eint`egrent les trames d´ecod´ees tardivement par Tetrys dans le processus de lecture. L’´etude pr´eliminaire `a montr´e que la combinaison de Tetrys et de ces codecs permettront d’am´eliorer sensiblement la qualit´e de la vid´eo.

Les applications `a contraintes de d´elai ne sont pas le seul cas d’application de Tetrys.

Dans les DTNs, nous avons montr´e que contrairement aux m´ecanismes existant, la ro-bustesse de la configuration de Tetrys permet le support des applications destreaming.

L’utilisation de Tetrys comme m´ecanisme de fiabilit´e de couche 3.5 permet de r´eduire l’impact des handover verticaux sur les protocoles de transports (compar´e aux proposi-tions utilisant les codes bloc).

De mani`ere plus prospective, nous avons montr´e que Tetrys rassemble les propri´et´es requises pour la transmission dans les r´eseaux anarchiques. Nous avons impl´ement´e une solution compl`ete dont l’´evaluation `a permis de montrer que le concept de r´eseaux anarchiques peut remplacer avantageusement son ´equivalent `a contrˆole de congestion, notamment au regard de la taille des buffers requis dans le r´eseau. Cela reste vrai aussi bien pour l’efficacit´e, l’´equit´e, l’´equit´e et les diff´erents types d’applications support´ees (temps r´eel).