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
thi_all@hotmail.com, azere@pop.com.br, williama.avila@gmail.com

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.