Conclus˜ ao do cap´ıtulo

usu´arios poderia, a princ´ıpio, ter um custo de processamento, e como conseq¨uˆencia, di-minuir o desempenho da rede.

Com a finalidade de avaliar, de maneira pr´atica, o real impacto da solu¸c˜ao no desempe-nho da rede, foram realizados dois experimentos semelhantes, que avaliam o desempedesempe-nho relativo `a taxa de transmiss˜ao. No primeiro, um fluxo de dados TCP foi enviado a partir do ponto 4 da topologia at´e um servidor, localizado fora da rede. Para este teste, o ponto 17 foi desativado, fazendo com que a rede contasse com apenas um gateway (o ponto 7).

Neste cen´ario, o experimento foi realizado com e sem a implementa¸c˜ao do DynTun. Os resultados obtidos podem ser vistos no gr´afico da Figura 3.8a. A m´edia ´e referente a 12 repeti¸c˜oes de 5 minutos para cada s´erie.

Claramente a utiliza¸c˜ao do DynTun n˜ao afetou o desempenho neste cen´ario. Em ambas as situa¸c˜oes, as m´edias foram bastante pr´oximas com uma ligeira desvantagem para o cen´ario em que a solu¸c˜ao foi utilizada. Ao se considerar o desvio padr˜ao das medidas, pode-se dizer que o impacto foi desprez´ıvel.

No segundo experimento, ao inv´es de utilizar fluxos TCP, optou-se por utilizar fluxos UDP, variando a taxa de transmiss˜ao de 1Mbps a 16Mbps. Neste caso, novamente os experimentos tiveram 5 minutos de dura¸c˜ao, por´em foram realizados apenas uma vez. A Figura 3.8b resume os resultados.

Novamente os dois cen´arios obtiveram resultados bastante pr´oximos para todas as taxas avaliadas. Isso demonstra que, embora a solu¸c˜ao proposta provoque um aumento no processamento realizado nos pontos de acesso, na topologia avaliada, este impacto n˜ao foi significativo diante do desempenho do canal de comunica¸c˜ao. Vale ressaltar ainda que as capacidades do hardware dos pontos de acesso utilizados neste experimento s˜ao bastante limitadas. O clock do processador ´e de 216 MHz e a mem´oria RAM dispon´ıvel

´e de apenas 16MB, valores bastante limitados.

3.7 Conclus˜ ao do cap´ıtulo

Para permitir um crescimento incremental, redes mesh podem utilizar a t´ecnica multi-homing. Esta t´ecnica contribui para combater a queda de desempenho, causada pelo aumento no n´umero de saltos entre os usu´arios e um gateway. Como demonstrado no primeiro teste na Se¸c˜ao 3.6, a simples combina¸c˜ao das t´ecnicas de multi-homing e NAT pode prejudicar os usu´arios. Tal preju´ızo decorre da quebra de uma grande quantidade

3.7 Conclus˜ao do cap´ıtulo 36

Figura 3.8: Demonstra¸c˜ao do baixo impacto da solu¸c˜ao sobre diferentes fluxos de dados.

das conex˜oes dos usu´arios. Tal efeito negativo certamente prejudica a qualidade da rede percebida pelo usu´ario. Portanto, ´e requerido um mecanismo que evite este problema.

A solu¸c˜ao DynTun ´e uma implementa¸c˜ao real e funcional, que resolve o problema da intera¸c˜ao entre as t´ecnicas demulti-homing e NAT, preservando a semˆantica das conex˜oes dos usu´arios. Apesar do DynTun ter como foco evitar as quebras nas conex˜oes, os testes da Se¸c˜ao 3.6.2 demonstraram um real aumento na capacidade da rede, tanto no quesito banda agregada de seus usu´arios, quanto no significativo aumento, em uma ordem de magnitude, da taxa da vaz˜ao das conex˜oes dos usu´arios que anteriormente se encontravam a mais saltos dos gateways.

As Se¸c˜oes 3.4 e 3.5 possuem v´arios itens que levantam a suspeita de que o DynTun po-deria impactar negativamente no desempenho da rede, devido ao processamento adicional necess´ario ao gerenciamento dos t´uneis. Contudo, os dois ´ultimos testes demonstraram o baixo impacto do DynTun no desempenho da rede.

A implementa¸c˜ao do DynTun, apesar de ser moldada `a rede Remesh, ´e tamb´em aplic´avel a outras redes, pois os crit´erios adotados s˜ao t˜ao restritivos que facilitam sua adapta¸c˜ao `as caracter´ısticas de outras redes. Os dois itens que podem precisar de adapta¸c˜ao s˜ao a descoberta de gateways e a medi¸c˜ao da qualidade das rotas.

Alguns trabalhos futuros incluem considerar a capacidade e carga de utiliza¸c˜ao de cada

3.7 Conclus˜ao do cap´ıtulo 37

gateway; oferecer suporte a QoS; evitar que conex˜oes de uma mesma aplica¸c˜ao sejam tu-neladas paragateways distintos, por causa de restri¸c˜oes que algumas aplica¸c˜oes possuem;

investigar se o DynTun pode ser modificado para suportar `a mobilidade do dispositivo cliente; adicionar mecanismos de criptografia nos t´uneis, com o objetivo de proteger os dados dos usu´arios e como ´ultimo trabalho futuro, criar t´uneis que passem um por um ga-teway intermedi´ario, com a finalidade de diminuir o uso de enlaces sem fio da rede mesh, ao utilizar o backbone cabeado que interconecta os gateways. Esta ´ultima modifica¸c˜ao resolve o efeito negativo, da atual implementa¸c˜ao, causado pela n˜ao utiliza¸c˜ao do melhor gateway em cada instante de tempo da vida de uma conex˜ao. Portanto, esta modifica¸c˜ao possui o potencial de melhorar, ainda mais, o aumento da capacidade, demonstrada pela Se¸c˜ao 3.6.2.

Este cap´ıtulo tratou de uma solu¸c˜ao para ´area de escalabilidade, bem como apresen-tou uma solu¸c˜ao que permite `as redes mesh expandirem as suas topologias e, portanto, estenderem a sua ´area de cobertura. Este crescimento, com a solu¸c˜ao, pode ter seu desem-penho melhorado com o uso de multi-homing, mesmo quando o uso de NAT ´e desej´avel.

No pr´oximo cap´ıtulo ser´a abordada a ´area de gerˆencia, que ´e um t´opico de relevˆancia para as redesmesh que possuem uma topologia extensa.