Tcp Veno - Trabalho

TCP Veno Thiago Fernandes Lemos, Mauro E. M. De Azeredo, William Avila Chaves Tecnólogo em Redes de Computadores – Centro Universitário La Salle Avenida Victor Barreto, 2288 – 92.010-000 – Canoas – RS – Brasil [email protected], [email protected], [email protected]

Resumo. Redes sem fio, diferentemente das redes cabeadas, possuem um grande problema com perdas de pacotes ocasionadas por erros de bit aleatórios. Para tratar essa questão, foram unidos e otimizados os algoritmos de dois flavors do protocolo TCP(Transmission Control Protocol), o TCP Reno e o TCP Vegas, nascendo assim o TCP Veno. Trata-se de um mecanismo de controle de congestionamento fim-a-fim que trata diferentemente perdas de pacote ocasionadas por congestionamento de perdas por erros de bits aleatórios, e que ainda tem como grande vantagem o fato de possuir alta conpatibilidade e flexibilidade. Abstratc. Wireless networks unlike cable network, has a big issue with bit errors packet loss. To solve this problem, the two flavors of TCP's, Reno and Vegas, algorithms were united and optimized, creating the TCP Veno, one algorithm which can act without affect anothers contestant's connections, which apply for example, the TCP Reno.

1. Introdução Cada vez mais se tornam populares as redes sem fio, e sua utilização é difundida tanto nas redes empresariais como nas redes domésticas. As redes sem fio são diferentes das redes cabeadas, possuem um grave problema em relação a perda de pacotes, além da perda por congestionamento na rede, tornam-se também significativos outros tipos de perdas devido as altas taxas de erros de bit do ambiente. Em redes cabeadas, o flavor TCP mais utilizado atualmente é o Reno, que utiliza o algoritmo de janela deslizante. Para controlar o tamanho desta janela, é utilizado o algoritmo de Slow Start(Inicialização Lenta) e o Congestion Avoidance(Controle de Congestionamento). Contudo, Reno trata qualquer perda de dados como sendo por congestionamento, pois foi projetado especialmente para redes cabeadas, onde não haveriam perdas significativas devido

ao ambiente, nem atrasos muito grandes, já que nas redes cabeadas geralmente a velocidade é muito maior que nas redes sem fio. Com o abjetivo de aproveitar melhor a largura de banda na internet, foi criado o flavor TCP Vegas, que implementa um controle de congestionamento pró-ativo. Porém, quando ele coexiste com outras conexões do tipo Reno, deixa de ser tão eficiente e sua performance diminui drasticamente. Para criação do Veno, foi levado em consideração os pontos positivos de cada um desses dois flavors. Do vegas, seu algoritmo foi utilizado para detectar quando a perda de pacotes ocorre devido a congestionamento da rede, ou quando ocorrre por algum fenômeno aleatório. Do Reno, foi feita uma otimizado para que houvesse uma diferenciação nas ações tomadas, de acordo com o motivo da perda de pacotes. Dessa forma, a diminuição da taxa de envio será menor quando a perda de pacotes for ocasionada por um fenômeno aleatório, aproveitando assim melhor banda da rede. Destes flavors nasceu, então, o TCP Veno, mesclando o nome de Reno e Vegas, assim como suas funcionalidades, de forma a otimizar as conexões sem fio. O artigo é composto de alguns tópicos: Seção 2 aboradremos como funcionam os algoritmos do TCP Veno. E ao final, teremos a conclusão.

2. TCP Veno O TCP Veno lida com a perda de pacotes utilizando, como base, o algoritmo Vegas para detectar qual o motivo da perda, se foi por congestionamento ou aleatória. Vegas tenta sempre manter a fila de pacotes do link baixa, alterando o tamanho da janela deslizante (sliding window) constantemente. Porém, quando Reno está ativo também na conexão, seu desempenho baixa, pois Reno aumenta o tamanho de sua janela e somente a diminui caso comece a perceber perdas. Veno, ao contrário de Vegas, usa a fila de pacotes para indicar quando a conexão esta em estado de congestionamento, e não para ajustar o tamanho da janela. Veno procura analisar, através do algoritmo retirado do Vegas, se a fila dos pacotes se encontra abaixo de um certo limite, que define se a conexão está em estado de congestionamento ou não. Se as perdas de pacotes ocorrerem enquanto a conexão estiver abaixo desse limite, então ele considera que o motivo é uma causa aleatória, já se este limite for excedido, ele assume que o motivo é congestionamento. Veno utiliza dois algoritmos modificados do Reno: O algoritmo de Inicialização Lenta e o algoritmo de Crescimento Aditivo. O algoritmo de Inicialização Lenta do Reno funciona da seguinte forma: Define o tamanho inicial da janela como 1 e começa a enviar os pacotes, após isso, toda vez que receber um ACK do pacote enviado, o tamanho da janela é aumentado em mais 1, ele aumenta de 1 para 2, depois de 2 para 4 após a segunda RTT, e assim por diante. Portanto, implementa um crescimento exponencial, que ocorre até que o tamanho da janela atinja um determinado limite, marcado pelo parâmetro ssthresh. O Veno implementa esse algoritmo sem nenhuma modificação. O algoritmo de Crescimento Aditivo utiliza como ponto inicial o parâmetro ssthresh. Quando o tamanho da janela está abaixo do número definido no ssthresh, então o algoritmo de Inicialização Lenta será utilizado para ajustar o tamanho da janela. Caso o tamanho da janela seja maior que o valor determinado no ssthresh, a taxa de aumento da janela é reduzida, de forma que o crescimento passa a ser de 1 em 1, para evitar congestionamento. No Reno o

valor do ssthresh inicial é de 64 kB. Veno implementa uma pequena mudança nesse algoritmo. Caso tenha verificado que o limite que define a ocorrência eminente de congestionamento na rede tenha sido ultrapassado, usando, para isso, o algoritmo herdado do Vegas, ele aumenta o tamanho da janela apenas a cada 2 RTT. Dessa forma, garante que as conexões fiquem operacionais por mais tempo. Se a rede não estiver em estado de congestionamento, o Veno procede da mesma maneira que o Reno.

Figura 1. TCP Veno quando não há perda aleatória.

Figura 2. TCP Reno quando não há perda aleatória.

Como visto na Figura 1 e na Figura 2, Veno é mais constante pois não aumenta o tamanho da janela como o Reno, o que faz com que haja uma diferença entre ambos em questão de tempo e oscilações. Desta forma, Veno consegue ter até 40% menos perdas por congestionamento. Neste quesito, Veno é totalmente diferente de Vegas, que utiliza o método de diminuir o tamanho da janela quando ele atinge o ponto crítico. Reno utiliza dois métodos para detectar a perda de pacotes. Um deles funciona caso o receptor não receba um ACK de um pacote enviado até o timeout, então Reno assume que este pacote se perdeu devido ao congestionamento, utilizando assim o algoritmo de Inicialização Lenta com o ssthresh definido como o tamanho da janela/2, sendo que o tamanho da janela é definido em 1. Desta forma há um redução drástica da taxa de envio. Veno não modifica esta parte do algoritmo. Reno também implementa um outro algoritmo, que faz com que toda vez que um receptor receba um pacote fora de ordem, envie um ACK solicitanto o envio do pacote que faltou para o originador dos dados, este ACK, a princípio, é uma duplicação, então ele o ignora num primeiro momento, porém, após o recebimento do terceiro ACK repetido, ele entenderá que ocorreu uma perda, isso se o temporizador não estiver estourado (Time Out). Este último algoritmo é também conhecido como Retransmissão Rápida. Para auxiliar o algoritmo de Retransmissão rápida, é utilizado um segundo algoritmo, chamado de Recuperação rápida. Reno, após retransmitir o pacote perdido, redefine o ssthresh para o tamanho da janela/2 e redefine o tamanho da janela para o valor atualizado do ssthresh. Veno se comporta diferentemente apenas quando a rede não esta em estado de

congestionamento, ou seja, quando a perda provavelmente for ocasionada por um erro de bit aleatório. Ele redefine o tamanho da janela para: cwnd*(4/5), onde cwnd é o tamanho da janela antes da ocorrência da perda, e o valor da ssthresh para: cwnd/2. Foram realizados experimentos que mostraram que, para não haver uma redução drástica no tamanho da janela, é recomendado reduzir mais que 3/4, assim Veno possui maior imunidade contra a perda de pacotes ocasionada aleatoriamente. No geral, Veno apenas faz algumas modificações nos algoritmos de Incremento Aditivo e Decremento Multiplicativo , todos os outros mecanismos do Reno foram utilizados exatamente da mesma forma no. Faz, portanto, apenas algumas modificações no algoritmo no lado de quem envia os dados.

3.Conclusão Redes wireless introduziram um novo tipo de problema, que deve ser tratado, no que diz respeito a significativas taxas de perda de pacotes por causas aleatórias. Para resolver, ou pelo menos amenizar, este problema foi criado o TCP Veno. TCP Veno é um mecanismo de controle de congestionamento que otimiza o TCP Reno através do uso de um algortimo retirado do TCP Vegas, tal algoritmo permite que ele monitore o nível de congestionamento na rede e diferencie perdas de pacote ocasionadas por congestionamento de perdas por erros de bit aleatórios. Isso permite que diferentes atitudes sejam tomadas de acordo com a situação diagnosticada, o que o torna um Flavor mais satisfatório para lidar com redes wireless. As modificações impostas pelo TCP Veno são implementadas somente no lado de quem envia, não precisando ser implementado também em todos os receptores. Dessa maneira, pode ser aplicado apenas nos hosts que enviem grandes quantidades de dados, como servidores web, por exemplo. Essa caracteristica facilita sua implementação em uma rede de larga escala e o torna compatível com outros tipos de conexões concorrentes (ex: Reno). Pode se dizer também que ele é bastante flexível em relação ao meio de transmissão de dados, seu funcionamento é satisfatório tanto em meios cabeados, quanto em meios wireless.

4.Referências Soung C. Liew e Cheng Peng Fu (2003). TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks, páginas 216–228. IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 21, NO. 2.