Proposta de um AQM Distribuído Simples para Melhoria do Desempenho do TCP em Roteadores Sem Fio

Transcrição

1 Proposta de um AQM Distribuído Simples para Melhoria do Desempenho do TCP em Roteadores Sem Fio Marcos Talau 1, Mauro Fonseca 2, Anelise Munaretto 3 1 Departamento Acadêmico de Informática Universidade Tecnológica Federal do Paraná (UTFPR) Ponta Grossa PR Brasil 2 Programa de Pós-Graduação em Informática (PPGIa) Pontifícia Universidade Católica do Paraná PUCPR Curitiba PR Brasil 3 Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial (CPGEI) Universidade Tecnológica Federal do Paraná (UTFPR) Curitiba PR Brasil talau@users.sf.net, mauro.fonseca@ppgia.pucpr.br, anelise@utfpr.edu.br Abstract. This paper presents a cross-layer mechanism to improve the performance of TCP in networks where the router has only one network interface, such as in adhoc wireless network. The method is compatible with any TCP implementation and acts as an active queue management (AQM), performing the change of the window field of the TCP header as the rate of use of the router queue. Comparative tests were conducted with Droptail and RED. The results indicated that the method increased throughput and fairness between flows, and also reduced the number of losses and delays. Resumo. Este artigo apresenta um mecanismo cross-layer para melhorar o desempenho do TCP em redes onde o roteador tem apenas uma interface de rede, como em redes sem fio adhoc. O método é compatível com qualquer implementação TCP e atua como um gerenciador de fila ativa (AQM), realizando a alteração do valor do campo janela dos cabeçalhos TCP de acordo com a taxa de utilização da fila do roteador. Foram realizados testes comparativos com o Droptail e o RED. Os resultados indicaram que o novo método aumentou a vazão e a justiça entre os fluxos, e também reduziu o número de perdas e atrasos. 1. Introdução O protocolo de controle de transmissão (TCP) é um protocolo da camada de transporte que oferece transferência confiável de dados, serviço orientado a conexão, controle de fluxo, e controle de congestionamento [Kurose e Ross 21]. O controle de fluxo é utilizado para que a fonte e o receptor informem a quantidade de dados que conseguem receber a cada momento, e o controle de congestionamento é uma medida que tenta prever a quantidade de dados que a rede irá suportar, isso normalmente é feito com o uso de algoritmos, como o slow-start [Jacobson 1988], utilizados pelas fontes TCP. Já é bastante conhecido que o controle de congestionamento presente no protocolo de transporte TCP não funciona adequadamente em redes onde o meio físico está 25

2 sujeito a falhas, como em redes sem fio [Balakrishnan et al. 1995] [Leung e Yeung 24] [Zhang et al. 28] [Zhang e Feng 29]. Alguns trabalhos da literatura sugerem que mecanismos no meio da rede podem auxiliar no controle de congestionamento. Em [Jain e Dovrolis 23] foi verificado que com a informação sobre a banda disponível é possível determinar a taxa de transmissão mais adequada, não sendo necessário adotar mecanismos de controle, como, por exemplo, o slow-start. [Floyd e Jacobson 1993]: neste trabalho os autores afirmam que o gateway é o local mais eficaz para se detectar um congestionamento. Em [Hasegawa e Murata 26] foi-se verificado que talvez a melhor forma para se evitar um congestionamento seja feita a partir de ações no meio da rede, que naturalmente refletem nos pontos finais de uma conexão TCP. Outros trabalhos, como em [Jiang et al. 29], sugerem a redução da complexidade das implementações TCP; a atuação de mecanismos no meio da rede podem favorecer tal processo. Levando em consideração principalmente os problemas do TCP em redes sem fio, e a recomendação do uso de mecanismos no meio da rede, neste trabalho é proposto um método cross-layer, compatível com qualquer implementação TCP, para atuar como gerenciador de fila ativa (AQM), visando melhorar o desempenho do protocolo TCP onde o roteador tem apenas uma interface de rede, como em redes sem fio adhoc. Na próxima Seção é apresentado o método e sua implementação no ns-3. A Seção 3 traz detalhes das simulações realizadas. Seguindo com os resultados (Seção 4), finalizando com as conclusões. 2. A Proposta Uma das causas de um congestionamento de rede (em um tempo t) é a transmissão de dados em quantidade superior às capacidades (no instante t) da rede. Buscando evitar este e outros problemas, neste artigo é proposto o método cross-layer denominado ECC (early congestion control). O método é um AQM derivado (fork) do Droptail, possuindo todas as suas características e comportamentos. O que o diferencia do Droptail é a criação de um recurso: a alteração do valor do campo janela do cabeçalho TCP de segmentos que estiverem saindo da fila, isto é realizado com a aplicação da Equação 1. f(w) = { Q q w Q w q > Q t caso contrário (1) onde Q representa o tamanho total (em bytes) da fila do roteador; q Q e indica a quantidade de bytes da fila que estão sendo utilizados; t é uma constante entre [,1]; e w corresponde ao valor, em bytes, da janela do cabeçalho TCP. Quando a quantidade de bytes utilizados na fila, q, for superior ao limiar Q t, o valor do campo janela do cabeçalho TCP do segmento é reduzido proporcionalmente à porcentagem ( Q q ) de bytes Q disponíveis (livres) na fila; caso isto não ocorra o valor do campo janela permanece o mesmo. O objetivo do ECC é a realização de um controle adicional da vazão dos fluxos TCP para evitar que a fila do roteador fique cheia, e assim inicie um congestionamento. Ele é compatível com qualquer implementação TCP, e para utilizá-lo é somente necessário a sua instalação em um roteador da rede. 26

3 Apesar do nome ser semelhante, é importante destacar que o ECC tem um comportamento diferente do AQM RED (random early detection). O RED utiliza um mecanismo para monitorar a média do tamanho da fila realizando um descarte probabilístico de segmentos, enquanto o ECC funciona da mesma forma que o Droptail, ou seja, realiza o descarte de pacotes apenas quando a fila estiver cheia, além de possuir a característica própria de reduzir o valor do campo janela do cabeçalho TCP proporcionalmente a quantidade de bytes disponíveis na fila. O ECC tem um comportamento de redução do valor do campo janela dos segmentos TCP de forma proporcional ao nível de utilização da fila do roteador, quanto mais a fila fica cheia, mais as janelas são reduzidas. Este comportamento foi criado para tentar se evitar que a fila fique cheia. Nas Figuras 1 e 2 são exibidas as taxas de utilização da fila de um roteador durante uma simulação; na Figura 2 o método ECC foi utilizado, e na outra o AQM padrão (Droptail). Pode se observar que o ECC manteve o uso da fila mais controlado, apresentando uma baixa variação. 1 uso da fila (em bytes) tempo (segundos) Figura 1. Taxa de utilização da fila do roteador com o uso do AQM Droptail. 1 uso da fila (em bytes) tempo (segundos) Figura 2. Taxa de utilização da fila do roteador com o uso do AQM ECC. 27

4 O ECC tem uma limitação importante: ele só funciona em roteadores que tenham somente uma interface de rede, como em redes sem fio adhoc. Isto é explicado no caso a seguir: o ECC alterou o campo janela do cabeçalho TCP dos segmentos enviados pelo receptor, para que ela ficasse compatível com a quantidade de bytes livres da fila do roteador, desta forma a fonte TCP irá transmitir sua rajada de acordo com a janela do receptor e também com a capacidade atual da fila do roteador. Se o roteador tem mais de uma interface (logo, mais de uma fila), por exemplo, duas, os segmentos da fonte irão trafegar pela fila f1, e os do receptor irão trafegar pela fila f2, logo o método não irá funcionar conforme o esperado. Exemplo de funcionamento da proposta: Considere que um roteador tem uma fila com capacidade de 1 KB. O nível de utilização do ECC foi definido para 4% da fila (t =.4), logo, quando o nível de utilização da fila atingir esta porcentagem o valor do campo janela dos segmentos TCP começará a ser alterado. Após um intervalo de tempo o roteador passa a ter 65 KB na fila, este valor, que equivale a 65% da fila, é maior que o nível de utilização definido, logo, quando um segmento (com janela TCP = 3) for sair da fila a sua janela será atualizada para 15, ou seja, o campo janela foi reduzido de acordo com a porcentagem de bytes disponíveis na fila do roteador Implementação no ns-3 O método foi implementado no simulador de rede ns-3, uma escolha natural seria a utilização do ns-2, porém ele não oferece uma implementação TCP que suporte o uso de janelas [ns-2-limitations 211]. O ns-3 é um simulador de rede baseado em eventos discretos projetado para modelar tráfego real de redes de computadores, é também um software livre (GPLv2), e seu código fonte é orientado a objetos escrito em linguagem C++ [ns-3 213]. Neste trabalho foi utilizado a versão 3.18 (a última lançada até o presente). A implementação foi feita junto ao módulo wifi. Neste, o AQM padrão fica na classe WifiMacQueue. Utilizou-se herança desta classe para criar uma nova. Na nova classe foi reescrito o método de Dequeue, que é responsável pela retirada de pacotes da fila, realizando ao seu término o retorno do respectivo pacote. Os códigos do ECC foram inseridos antes deste retorno ser realizado, sendo retornado um pacote possivelmente atualizado pelo método, possivelmente pois o ECC age apenas quando o nível t é atingido. 3. Modelo de Simulação Os testes foram realizados em uma rede sem fio adhoc, onde os nós foram posicionados para existir um nó central com um conjunto de n nós a esquerda, e n nós a direita. A Figura 3 ilustra a topologia. A rede adhoc foi configurada para utilizar o padrão IEEE 82.11a, com método de transmissão OFDM a 6 Mbps 1. Para o nó central ser utilizado como roteador na comunicação entre os nós da esquerda/direita foi utilizado o protocolo de roteamento on-demand distance vector (AODV). Nas simulações os nós da esquerda foram configurados para serem fontes TCP ([F1,Fn]), e os da direita receptores TCP ([R1,Rn]). Durante a simulação cada fonte fez uma conexão com um receptor, e dados foram transmitidos até o término da simulação. 1 Atualmente no ns-3 não são suportadas maiores velocidades para redes adhoc. 28

5 F1 R1 F2 R2 F3 R3 Fn Rn Figura 3. Topologia adhoc utilizada nas simulações. As fontes foram configuradas para utilizar o gerador de tráfego BulkSendApplication (ns- 3), que gera dados a uma taxa constante. Demais configurações: o AQM foi configurado apenas no nó central; variável t do ECC: 38.8 KB; tamanho da fila: 97 KB; RED: os parâmetros foram ajustados conforme o procedimento presente em [Wille et al. 24], ficando: minth: 3 KB, maxth: 48.5 KB, Qw/w q :.2, tamanho médio dos segmentos: 53 bytes; tamanho dos segmentos TCP: 1 bytes; algoritmo de controle de congestionamento: TCP New Reno. 4. Resultados O método proposto foi comparado ao Droptail e ao RED através de simulações no ns-3 com a utilização da topologia apresentada na seção anterior. Cada simulação foi executada durante o tempo de seis minutos. As simulações foram executadas com 4, 8, 12, 16, e 2 fluxos; os nós da esquerda foram utilizados como fontes TCP, e os da direita como receptores, cada nó fonte/receptor criou apenas um fluxo, logo para se aumentar o número de fluxos, mais nós fontes/receptores foram criados. Cada simulação foi executada 5 vezes, com diferentes sementes de números aleatórios. Nelas foram coletados dados referentes a vazão (recebida), perdas, e atraso e justiça. Os dados que são apresentados nas próximas subseções são referentes a média das 5 rodadas com um intervalo de confiança de 95% Vazão Foi coletada a vazão (throughput) recebida pelos receptores[r1,rn]. A Figura 4 exibe a vazão total (somatória der1 até Rn). Com a mudança do número de fluxos o método proposto teve pouca variação da vazão; o RED apresentou um comportamento semelhante, porém com média 27,41% menor. No Droptail a vazão foi bastante reduzida em função do número de fluxos; e comparado ao ECC seu desempenho foi em média 7,31% menor Perdas As perdas registradas foram do nó central onde o AQM estava presente. Elas ocorreram quando a fila ficou cheia (Droptail/ECC), ou quando o AQM produziu (RED). A Figura 5 exibe o número total de perdas. 29

6 1 8 Droptail RED ECC vazão (recebida) em KB número de fluxos Figura 4. Vazão recebida pelos receptores [R1, Rn]. 2 Droptail RED ECC total de perdas número de fluxos Figura 5. Número total de perdas (o ECC registrou poucas perdas (média de 25) por isso quase não aparece no gráfico). O uso do ECC levou a poucas (média de 25) perdas no roteador, por isto na Figura 5 os dados referentes ao método quase não aparecem. O baixo número de perdas com a utilização do ECC era previsto, pois o comportamento de reduzir a janela dos segmentos de acordo com o nível de utilização da fila leva a uma redução da taxa de transmissão das fontes. O Droptail e o RED tiveram o número de perdas em função do número de fluxos, comparado ao ECC, o número de perdas foi muito maior, porém, nestes métodos as perdas são esperadas e necessárias. As perdas na rede ativam mecanismos de controle de congestionamento das fontes TCP, um outro fator também considerado na ativação é o recebimento de três ACKs 3

7 duplos (triple dupacks). Um ACK duplicado é enviado quando um segmento fora de ordem é recebido, a recepção de três indica congestionamento na rede [Stevens 1997]. A Figura 6 exibe o número total de triple dupacks registrados nas simulações. Comparado ao Droptail e ao RED, o ECC registrou um número bastante reduzido de triple dupacks. Com o menor registro de triple dupacks pode-se dizer que a rede ficou menos congestionada. número de triple dupacks Droptail RED ECC número de fluxos Figura 6. Número total de Triple dupacks Atraso e Justiça O atraso refere-se ao tempo utilizado para um pacote ir da fonte até o destino final. A Figura 7 apresenta o atraso médio. 2 Droptail RED ECC atraso (em segundos) número de fluxos Figura 7. Atraso médio registrado. 31

8 Pode-se observar que o atraso aumentou de acordo com o número de fluxos. Comparando, o ECC teve um atraso médio de 12,63% menor que o Droptail, e 42,54% menor que o RED. Analisando isoladamente os AQMs Droptail e ECC: o algoritmo do Droptail é mais rápido que o do ECC pois não realiza a atualização de segmentos TCP, porém na prática o ECC causou uma redução de atrasos na rede, pois o seu uso trouxe redução de congestionamento de rede. A diferença de atrasos entre os fluxos foi utilizada para definir a justiça. Para gerar este dado: em cada rodada foi calculado o desvio padrão dos atrasos, após isso foi calculado a média e o intervalo de confiança do desvio padrão dos atrasos de todas as rodadas. A Figura 8 exibe estes dados. O desvio padrão dos atrasos também cresceu com o aumento do número de fluxos, o método ECC registrou o menor valor em cada teste, em comparação com os outros métodos isso indica que os fluxos tiveram um atraso mais uniforme, o que caracteriza uma maior justiça entre os fluxos; em números o ECC foi em média 112% mais justo que o Droptail. 8 7 Droptail RED ECC desvio padrão dos atrasos número de fluxos Figura 8. Desvio padrão dos atrasos Análise Geral Verificando os dados das simulações realizadas pode-se concluir que o ECC foi eficaz em reduzir o congestionamento de rede, e consequentemente aumentar o desempenho do protocolo TCP. O uso do seu mecanismo de atualização de janelas em função do nível de utilização da fila do roteador levou a uma maior vazão, poucas perdas, e a um menor atraso. Com o crescimento do número de fluxos a disputa por recursos de um roteador aumenta, se o aumento não for controlado a fila irá ficar cheia, resultando em perdas de pacotes. As fontes TCP conseguem detectar estas perdas, e quando isso acontece é feita uma redução da taxa de transmissão (de acordo com o algoritmo de controle de congestionamento que ela utiliza). Então, quando o número de fluxos aumenta, se as 32

9 técnicas de controle de congestionamento utilizadas não regularem adequadamente os recursos que a rede possuí, a vazão total (soma de todos os fluxos) irá ser reduzida. A utilização do ECC conseguiu manter a vazão constante, independentemente do número de fluxos. As perdas na fila do roteador ocorrem quando ela fica cheia. O mecanismo do ECC foi eficiente em evitar que ela ficasse cheia; poucas perdas foram registradas com o seu uso. A utilização do ECC também reduziu bastante o número de ACKs triplos, e um pouco do atraso, o que indica que a rede ficou menos congestionada. 5. Conclusões Este trabalho apresentou um método (chamado de ECC), que atua como AQM, para melhorar o desempenho do protocolo TCP em redes onde o roteador tem apenas uma interface de rede, como em redes sem fio adhoc. O ECC baseia-se no ajuste do campo janela dos segmentos TCP de acordo com a taxa de utilização da fila do roteador. O método foi comparado com o Droptail e o RED, sendo coletados dados referentes a vazão, perdas, atrasos, e justiça. Comparado aos outros métodos, o método proposto produziu uma maior vazão. O número de perdas foi bastante reduzido, assim como o número de ACKs triplos. O atraso também foi menor, e a justiça entre fluxos foi maior. O uso do ECC reduziu significativamente o número de ACKs triplos (Triple dupacks). É esperado que o desempenho do TCP aumente ainda mais com a utilização de algoritmos de controle de congestionamento que utilizem este número de uma melhor forma que o TCP New Reno. Os resultados dos testes realizados indicaram que o método melhorou o desempenho do protocolo TCP. Testes futuros podem ser feitos com a utilização de fluxos UDP; diferentes topologias adhoc; uso de topologias sem fio em infraestrutura; diferentes algoritmos de controle de congestionamento nas fontes; e redes sem fio com maiores velocidades. Referências Balakrishnan, H., Seshan, S., e Katz, R. H. (1995). Improving reliable transport and handoff performance in cellular wireless networks. Wireless Networks, 1(4): Floyd, S. e Jacobson, V. (1993). Random early detection gateways for congestion avoidance. IEEE/ACM Transactions on Networking (TON), 1(4): Hasegawa, G. e Murata, M. (26). TCP symbiosis: congestion control mechanisms of TCP based on Lotka-Volterra competition model. In Interperf 6: Proceedings from the 26 workshop on Interdisciplinary systems approach in performance evaluation and design of computer & communications sytems, page 11, New York, NY, USA. ACM. Jacobson, V. (1988). Congestion avoidance and control. In SIGCOMM 88: Symposium proceedings on Communications architectures and protocols, pages , New York, NY, USA. ACM. 33

10 Jain, M. e Dovrolis, C. (23). End-to-end available bandwidth: measurement methodology, dynamics, and relation with TCP throughput. IEEE/ACM Transactions on Networking (TON), 11(4): Jiang, S., Zuo, Q., e Wei, G. (29). Decoupling congestion control from TCP for multihop wireless networks: semi-tcp. In CHANTS 9: Proceedings of the 4th ACM workshop on Challenged networks, pages 27 34, New York, NY, USA. ACM. Kurose, J. e Ross, K. (21). Redes de computadores e a Internet: uma abordagem top-down. Addison Wesley, São Paulo, SP. Leung, K.-F. e Yeung, K. (24). G-Snoop: enhancing TCP performance over wireless networks. In Computers and Communications, 24. Proceedings. ISCC 24. Ninth International Symposium on, volume 1, pages , Alexandria, Egypt. IEEE Press. ns-2-limitations (211). ns-2 Limitations. ns-limitations.html. Acesso em: 25 out. 213, 23:53. ns-3 (213). ns-3. Acesso em: 1 nov. 213, 23:29. Stevens, R. W. (1997). RFC 21: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. Wille, E. C. G., Mellia, M., Leonardi, E., e Ajmone-Marsan, M. (24). Design and Analysis of IP Networks with End-to-End QoS Guarantees. In XXI Simpósio Brasileiro de Telecomunicações, Belém-Pará, Brasil. Sociedade Brasileira de Telecomunicações. Zhang, Y. e Feng, G. (29). A new method to improve the TCP performance in wireless cellular networks. In Communications, Circuits and Systems, 29. ICCCAS 29. International Conference on, pages , Milpitas, California, USA. IEEE Press. Zhang, Y., Hu, J., e Feng, G. (28). SNOOP-based TCP Enhancements with FDA in wireless cellular networks: A comparative study. In Communications, Circuits and Systems, 28. ICCCAS 28. International Conference on, pages , Fujian Province, China. IEEE Press. 34