DISCUSSION G´EN´ERALE
L’article pr´esent´e dans le chapitre, 4, a permis d’affirmer que l’algorithme EffiCuts, trans- pos´e dans le contexte de SDN ne permet pas d’atteindre des performances d´ecentes. En effet, malgr´e une consommation de m´emoire raisonnable, le nombre d’acc`es m´emoire a tout sim- plement explos´e. Ce probl`eme est majoritairement du au nombre ´elev´e d’arbres `a parcourir, cons´equence directe de l’augmentation du nombre de champs consid´er´es.
Par ailleurs, il est aussi important de remarquer que, compar´e `a (Vamanan et al., 2010), o`u seuls 5 champs sont consid´er´es, la consommation m´emoire de l’algorithme pr´esent´e dans le chapitre 4 demeure dans le mˆeme ordre de grandeur. En effet, l’algorithme EffiCuts fait levier sur de multiples m´ethodes pour minimiser la valeur du facteur de r´eplication et ainsi minimiser l’espace occup´e par chaque r`egle, de telle sorte que l’augmentation de la taille des r`egles a un impact limit´e au niveau de la taille de la structure g´en´er´ee. De plus, les nombreux arbres construits dˆu `a la prise en compte de 12 champs, sont majoritairement de petits arbres, contenant un nombre faible voir tr`es faible de r`egles. Par cons´equent, ce type d’arbre a une influence tr`es restreinte au niveau de la taille de la structure de donn´ee g´en´er´ee. Ces deux justifications permettent d’expliquer les performances rencontr´ees par l’algorithme EffiCuts, dans sa version non optimis´ee, dans un contexte de SDN. Bien que l’extensibilit´e soit bonne en termes d’occupation m´emoire, l’extensibilit´e de cet algorithme est tr`es mauvaise concernant le nombre d’acc`es m´emoire.
Les trois optimisations pr´esent´ees dans (Stimpfling et al., 2013) permettent de r´eduire de mani`ere importante la consommation m´emoire ainsi que le nombre d’acc`es m´emoire et d’atteindre une performance acceptable pour envisager une impl´ementation mat´erielle ou logicielle. Ainsi le nombre d’acc`es m´emoire moyen a ´et´e r´eduit par un facteur 2, alors que la consommation m´emoire est r´eduite de 35% en moyenne par rapport `a EffiCuts.
N´eanmoins, on remarquera que l’optimisation “Leaf size modulation” est une optimisation partielle, dans la mesure o`u, dans le contexte pr´esent´e, on constate que ce param`etre a une influence sur la performance et notamment le nombre d’acc`es m´emoire mais que la performance est sujette `a variation. D`es lors, le probl`eme sous-jacent, `a savoir le parcours lin´eaire des feuilles, n’est pas trait´e. Ce point am`ene deux autres questions ; Quelle partie des arbres “comprimer” pour diminuer le nombre d’acc`es m´emoire ? et Peux-t-on proposer une alternative au parcours lin´eaire des feuilles ?. Le chapitre 5 vise `a apporter un ´eclairsissement `a ces questions.
Le second article pr´esent´e dans le chapitre 5, permet de pousser la reflexion plus loin, via une analyse d´etaill´ees de la performance et des probl`emes rencontr´es par EffiCuts dans le contexte de SDN. La solution propos´ee, AcceCuts va beaucoup plus en loin en termes de performance par rapport `a ce qui a ´et´e propos´e dans le chapitre 4. En effet, la r´eduction moyenne du nombre d’acc`es m´emoire atteind un facteur 3, et une diminution de 45% de l’occupation m´emoire est obtenue par rapport `a EffiCuts. La grande diff´erence entre ces deux chapitre repose sur la modification de la structure des feuilles introduite par AcceCuts, et qui impact drastiquement sur le nombre d’acc`es m´emoire en impactement de mani`ere tr`es limit´ee sur la taille de la structure de donn´ee g´en´er´ee. Il est par ailleurs int´eressant de noter que jusqu’`a pr´esent, dans la litt´erature, aucune contribution n’a ´et´e faite concernant la structure des feuilles.
Par ailleurs, l’article (Stimpfling et al., 2013) mentionne qu’en raison de l’absence de g´en´e- rateur de r`egles synth´etiques reprenant des caract´eristiques de tables de classification r´eelles, une m´ethode de g´en´eration de r`egles a ´et´e propos´ee combinant deux g´en´erateurs de r`egles, l’un, ClassBench permettant de cr´eer des r`egles avec des typages et l’autre, FRuG, dont les param`etres de g´en´eration sont laiss´es `a la discr´etion de l’utilisateur. Dans un tel cas, il parait impossible de configurer FRuG pour recr´eer des patrons de r`egles utilis´ees r´eellement dans des tables de classification. Certains sites offrent, `a des fins de recherche, des traces de paquets (CAIDA : The Cooperative Association for Internet Data Analysis) mais ces traces ne per- mettent pas de d´eterminer les caract´eristiques des r`egles associ´ees qui ont filtr´e ces paquets. Par cons´equent, la solution retenue a ´et´e de configurer FRuG afin d’encadrer la performance de l’algorithme test´e, en cr´eant deux sc´enarios permettant de simuler le meilleur ainsi que le pire des cas. N´eanmoins, une telle approche est discutable, non pas sur le principe, mais bien sur les param`etres qui ont ´et´e associ´es au meilleur et pire cas. Autant, il est peu important d’avoir un “meilleur cas” ´eloign´e (en dessous) du “meilleur cas” r´eel, dans la mesure o`u le seul risque est de ne pas obtenir des r´esultats potentiellement meilleurs. Autant un sc´enario illustrant le pire des cas et configur´e de mani`ere trop avantageuse peut ˆetre lourd de cons´e- quence. En effet, dans la litt´erature la performance des algorithmes est souvent ´etudi´ee par rapport au pire des sc´enarios, afin de garantir des performances, et ce sont ces mesures qui permettent de d´eterminer si oui ou non l’algorithme est digne d’int´erˆet ou non.
De mˆeme, la situation inverse est aussi envisageable, `a savoir que les param`etres entr´es pour configurer le g´en´erateur de r`egles repr´esentent certes un sc´enario engendrant la pire per- formance d’un point de vue th´eorique, mais rien ne dit que cette situation va ˆetre rencontr´ee dans un contexte de production. De fait, le pire des sc´enarios simul´es peut se situer tr`es loin du pire des sc´enarios r´eels et, donc, les performances r´eelles peuvent s’av´erer sensiblement meilleures que celles simul´ees. Il est important de consid´erer ces faits et de rappeler que la
seule simulation valable demeure celle effectu´ee avec des r`egles utilis´ees dans un environne- ment de production.
N´eanmoins, ces deux remarques demeurent valables dans le cas de l’algorithme AcceCuts pr´esent´e dans le chapitre 5, puisque ce dernier se base sur les mˆemes benchmark.