Discussões sobre os Experimentos da Fase 1

Nesta fase existem basicamente 3 pontos a serem discutidos:

1. verificar se a mudança do tamanho do pacote ocasiona alguma alteração considerável durante as transmissões com os protocolos estudados;

2. analisar o impacto causado em termos da vazão e da quantidade de dados transmitidos e perdidos quando efetua-se hand-off durante a transmissão de dados;

3. analisar o comportamento dos protocolos TCP, UDP e DCCP em termos de eqüidade (fairness).

Para o primeiro item, não foram constatadas fortes alterações de comportamento dos fluxos transmitidos por nenhum dos protocolos isoladamente, principalmente com relação às métricas vazão e jitter. Porém, observa-se algumas alterações no desempenho dos algoritmos TCP Reno, Cubic e V eno para os confrontos TCP × UDP e TCP × DCCP.

Para os confrontos TCP × UDP, a quantidade de dados transmitidos utilizando os algorit- mos T CP Reno, Cubic e V eno não foi satisfatória, considerando o agrupamento dos expe- rimentos em dois grupos: um com os experimentos utilizando pacotes de tamanho 512 bytes (Tabela 6.1) e o outro contendo os experimentos utilizando pacotes de tamanho 1424 bytes (Tabela 6.2). Ora, se as vazões dos protocolos TCP e UDP são praticamente as mesmas para os dois grupos de experimentos – isto pode ser observado nas linhas 1, 2 e 3 – então quanto maior o tamanho do pacote, maior a quantidade de dados que aquele fluxo deveria transmitir, considerando-se que o MTU da conexão 802.11g é de 1500 bytes, não ocorrendo portanto fragmentação de pacotes na camada de rede.

Por outro lado, não se observa este fato para os confrontos TCP × DCCP, independente dos algoritmos utilizados. Comparando-se os valores das vazões obtidas nos confrontos

TCP × UDP e TCP × DCCP apresentadas nas Tabelas 6.1 e 6.2, observa-se um equilíbrio entre estes valores. Por exemplo, nas Tabelas 6.1 e 6.2, a vazão média do TCP Reno foi de 3359,12 Kbits/s e 3162,41 Kbits/s, respectivamente. Assim, se as vazões são praticamente as mesmas, então quanto maior o tamanho do pacote, mais dados aquele fluxo deveria ter transmitido. Isto aconteceu apenas para os confrontos TCP × DCCP. Neste caso, os três al- goritmos do TCP transmitiram mais dados quando o tamanho do pacote foi de 1424 KBytes. Isto era de se esperar, uma vez que o protocolo DCCP implementa controle de congestiona- mento e portanto permite que os fluxos TCP transmitam mais dados à medida que se aumenta o tamanho do pacote, considerando que o tamanho máximo para um pacote o valor do MTU menos o espaço ocupado no pacote pelos cabeçalhos dos protocolos das camadas de rede, transporte e de aplicação.

Portanto, pode-se concluir que, em transmissões onde os protocolos TCP e UDP com- partilham o mesmo canal de comunicação, aumentar o tamanho do pacote de 512 KBytes para 1424 KBytes não obtem-se melhorias consideráveis, mesmo considerando o algoritmo de controle de congestionamento V eno. Isto sugere que internamente o TCP perdeu mais dados quando foram utilizados pacotes de 1424 KBytes. Neste caso, futuros estudos poderão avaliar qual deve ser o tamanho ideal do pacote de dados para minimizar a quantidade de pa- cotes perdidos por parte do TCP. Uma discussão neste contexto é apresentada em [WCSY07]. Com relação às execuções dos hand-offs, nos gráficos da Figura 6.1 é apresentada a evolução da transmissão do confronto TCP Cubic × UDP, que corresponde à linha 2 da Ta- bela 6.1. No gráfico da Figura 6.1(a), apresenta-se os valores médios da vazão alcançada pelos protocolos TCP e UDP. No gráfico da Figura 6.1(b), apresenta-se a relação quanti- dade de dados transmitidos pela quantidade de dados perdidos pelo protocolo UDP para este confronto. Os valores dos pontos plotados nos gráficos da Figura 6.1, foi calculado atra- vés da média aritimética dos valores de cada ponto para todas as repetições realizadas do experimento, neste caso para n = 5.

Note que, no gráfico da Figura 6.1(a), a taxa de transmissão do protocolo TCP diminuiu devido às execuções de hand-offs, onde ocorreram perdas de pacotes, o que se reflete nos algoritmos de controle de congestionamento do TCP e do DCCP. No caso do protocolo UDP, a taxa de transmissão permaneceu constante durante todo o tempo. No gráfico da Figura 6.1(b), constata-se um nível elevado de perda de dados quando se utiliza o protocolo UDP, sobretudo durante a execução dos hand-offs. É possível observar em torno do segundo 35, outro ponto de declínio da taxa de transmissão do protocolo TCP. Este fato pode ser explicado pelo início das transmissões dos dois fluxos UDP, onde também ocorreram perdas de pacotes.

Já nos gráficos da Figura 6.4 é apresentada a evolução da transmissão para o confronto TCP-Cubic × DCCP, que corresponde à linha 5 da Tabela 6.1. Os valores de cada ponto destes gráficos foram calculados da mesma forma que nos gráficos anteriores, com n = 9. Esta procedimento também foi adotado em todos os outros gráficos apresentados neste

0 1000 2000 3000 4000 5000 6000 7000 8000 0 50 100 150 200 250 300 Vazao (Kbits/s) Tempo (s)

TCP−Cubic x UDP: Vazao (512 bytes)

TCP−1 UDP−1 UDP−2

(a) Vazão alcançada pelos protocolos TCP e UDP.

0 5000 10000 15000 20000 25000 30000 0 50 100 150 200 250 300 Transmitido/Perdido (KBytes) Tempo (s)

TCP−Cubic x UDP: Carga Efetiva (512 bytes) Transmitido (KBytes)

Perdido (KBytes)

(b) Relação da quantidade de dados transmitidos pela quantidade de dados perdidos do protocolo UDP.

Figura 6.1: Fase 1: TCP × UDP: vazão e carga efetiva do confronto TCP-Cubic × UDP durante uma transmissão de 300 s, com tamanho de pacote 512 bytes e execução de hand- offsem 100 s e em 200 s.

0 1000 2000 3000 4000 5000 6000 7000 8000 0 50 100 150 200 250 300 Vazao (Kbits/s) Tempo (s)

TCP−Cubic x DCCP−2: Vazao (512 bytes) TCP−1 DCCP−1 DCCP−2

(a) Vazão alcançada pelos protocolos TCP e DCCP.

0 500 1000 1500 2000 2500 3000 0 50 100 150 200 250 300 Transmitido/Perdido (KBytes) Tempo (s)

TCP−Cubic x DCCP−2: Carga Efetiva (512 bytes) Transmitido (KBytes)

Perdido (KBytes)

(b) Relação da quantidade de dados transmitidos pela quantidade de dados perdidos do protocolo DCCP.

Figura 6.2: Fase 1: TCP × DCCP: vazão e carga efetiva do confronto TCP-Cubic × DCCP-2 durante uma transmissão de 300 s, com pacotes de 512 bytes e hand-offs em 100 s e em 200 s.

capítulo, exceto para os gráficos apresentados como resultados da Fase 3, que corresponde a uma execução do confronto.

No gráfico da Figura 6.2(a), a taxa de transmissão do protocolo TCP também diminuiu devido às execuções de hand-offs, pelos mesmos motivos do confronto TCP × UDP. No caso do protocolo DCCP, ocorreu uma leve diminuição na taxa de transmissão deste protocolo nos momentos de hand-off. No gráfico da Figura 6.2(b), constata-se um nível baixíssimo de perda de dados quando se utiliza o protocolo DCCP em confronto com o protocolo TCP. É possível observar que durante todo o tempo de transmissão, os protocolos TCP e DCCP compartilham a utilização do canal de transmissão de forma eqüinime.

Com relação a eqüidade entre os protocolos em termos de quantidade de dados transmi- tido por cada um dos protocolos, esperava-se que o protocolo UDP congestionasse a rede quando em confrontos com o TCP e com o DCCP, mas este fato ocorreu. Conclui-se então que há contenção de dados na fonte geradora, neste caso os dispositivos N 800. Como o poder de processamento de dados destes dispositivos é limitado, há uma limitação da velo- cidade com que os dados são processados e transmitidos na rede, considerando-se que neste caso o processo da aplicação IPerf ocupou menos tempo de utilização da CPU se comparado ao tempo de utilização da CPU em um computador desktop, por exemplo. Serão apresenta- das discussões neste sentido na Seção 6.2.1, onde observou-se um comportamento diferente: o protocolo UDP congestiona a rede para alguns casos e impede que os protocolos TCP e DCCP transmitam dados na rede.

Além das discussões apresentadas nesta seção, cabe relatar dois outros fatos ocorridos durante a execução dos experimentos nesta fase:

• observou-se desconexões repentinas da rede sem fio por partes dos dispositivos N800. Isto provavelmente está associado mais uma vez a capacidade de processamento e de gerenciamento de recursos por parte das aplicações em execução neste dispositivo, em particular da aplicação controladora (driver) da placa de rede sem fio deste dis- positivo. Para uma justificativa mais elaborada deste fato, sugere-se um estudo mais aprofundado, onde os focos seriam analisar se existe alguma situação em que o proces- sador deste dispositivo fica sobre-carregado, o que pode ocasionar tais desconexões; e também verificar se estas desconexões ocorrem devido às execuções dos hand-offs, onde por motivos desconhecidos no momento, o driver controlador da placa de rede sem fio desconecta do ponto de acesso sem fio;

• além do desempenho ruim do protocolo UDP para transmissão de dados em redes sem fio, principalmente no tocante à quantidade de dados transmitidos e à quantidade dos dados efetivamente recebidos – isto pode ser observado nas Tabelas 6.1 e 6.2, campo Transmitido / Perdido – em todas as transmissões realizadas utilizando o protocolo UDP, observou-se que este realizou entrega de pacotes de dados fora de ordem. A entrega de pacotes fora de ordem também ocorreu por parte do protocolo DCCP, porém

em proporções bem menores se comparado ao protocolo UDP. Essas proporções são equivalentes às perdas de pacotes do protocolo DCCP nos confrontos TCP × DCCP – Tabelas 6.1 e 6.2, campo Transmitido / Perdido, entre as linhas 4 e 9 (inclusive).