Universidade Federal de Campina GrandeDepartamento de Sistemas e Computação

Mestrado em Ciência da ComputaçãoDisciplina: Projeto de Redes

Professor: Marco Aurélio SpohnAluno: Dalton Cézane Gomes Valadares

Relatório de avaliação das simulações realizadas com os protocolos TCP e DCCP (CCID 2 e CCID 3)

Introdução

Este relatório tem o intuito de apresentar o que foi realizado durante o projeto da disciplina Projeto de Redes. Neste projeto foram realizadas simulações para avaliar a vazão de fluxos de dados entre nós utilizando, como protocolo de transporte, TCP e DCCP.

A idéia destas simulações foi comparar os dois protocolos citados, TCP e DCCP, utilizando a vazão dos fluxos de dados como métrica. Para o protocolo DCCP foram utilizados os mecanismos de controle de congestão CCID 2 e CCID 3.

Além de verificar os resultados obtidos e fazer a comparação entre os mesmos, no presente documento também é exposta uma breve descrição sobre cada protocolo.O relatório está organizado da seguinte forma: uma breve descrição do protocolo TCP é exposta na seção que segue a introdução (TCP – Transmission Control Protocol); logo em seguida há uma seção com algumas idéias do protocolo DCCP (DCCP – Datagram Congestion Control Protocol); após essa seção, são apresentados todos os dados da simulação em uma seção (Simulações), seguida de todos os resultados obtidos, em outra seção (Resultados obtidos); por fim, é apresentada uma breve conclusão e as referências bibliográficas.

TCP – Transmission Control Protocol

O TCP, protocolo de controle de transmissão, é um protocolo do nível de transporte e é um dos principais protocolos de rede existentes. Uma das principais vantagens do TCP é o fato de ser robusto e versátil, além de enviar dados na correta seqüência, sem erros, e realizando a verificação de corretude dos mesmos.

TCP é orientado à conexão, ponto a ponto, sendo necessário que a aplicação envie solicitação de conexão ao destino para realizar a transferência de dados. Confiabilidade é uma das principais características do TCP, sendo provida através de várias técnicas, recuperando pacotes perdidos e dados corrompidos, eliminando pacotes duplicados e recuperando ligações em caso de problemas com o sistema ou com a rede.

Para o estabelecimento e finalização da conexão, é necessária a realização de um handshake que permite a autenticação e o encerramento de uma sessão completa, com a garantia de que, ao final, todos os pacotes foram recebidos sem problemas. É possível transferir dados em ambas as direções porque o canal é full-duplex.

Os blocos de dados são entregues, pela aplicação, ordenadamente, em um tamanho arbitrário num fluxo de dados (freqüentemente octetos). Os dados são partidos em segmentos, mas a circulação dos pacotes na rede pode fazer com que os pacotes cheguem desordenados. O TCP, então, garante que o fluxo seja reconstruído no destinatário, graças aos números de seqüência.

O controle de fluxo no TCP se dá através da idéia de janelas deslizantes (campo janela do cabeçalho). O receptor envia mensagens ACK, sempre que recebe dados, confirmando a recepção dos segmentos. A quantidade máxima de bytes aceitos pelo receptor também pode ser determinada, especificando o tamanho máximo do buffer no campo janela do segmento. O transmissor deve respeitar o tamanho da janela permitido: o menor valor entre sua capacidade de envio e a capacidade informada pelo receptor.

Funcionamento do TCP

Durante uma conexão, três etapas são realizadas no protocolo TCP: estabelecimento da ligação, transferência de dados e término da ligação. Três passos são necessários para realizar o estabelecimento da ligação e quatro passos são necessários para o término da mesma. Alguns parâmetros, como número de seqüência, são inicializados no início para que a entrega ordenada e a robustez sejam garantidas durante a transmissão.

No estabelecimento da ligação, o cliente envia um pacote TCP com a flag SYN ativa e espera-se que o servidor aceite a ligação enviando um pacote SYN + ACK. Se o pacote não for recebido durante determinado tempo, ocorre timeout e o SYN pacote é reenviado. O cliente conclui o estabelecimento da ligação, respondendo com um pacote ACK e confirmando a aceitação do servidor. Durante este processo, são trocados os números de seqüência iniciais, entre os participantes da comunicação. Estes números de seqüência identificarão os dados ao longo do fluxo e servirão como contadores de bytes transmitidos durante a fase de transferência de dados. Por fim, o cliente é inserido, com uma conexão, em uma tabela do servidor. Esta tabela possui

um limite de conexões e, se ficar preenchida, as ligações são rejeitadas e os pacotes SYN subseqüentes são ignorados.

Na fase de transferência de dados, vários mecanismos asseguram a confiabilidade e a robustez do TCP, como: código detector de erros (detecção de falhas em certos segmentos), números de seqüência que garantem a entrega ordenada, temporizadores que ajustam e contornam atrasos e perdas de segmentos e confirmação de recepção.

No cabeçalho TCP, existe um par de números de seqüência: número de seqüência e número de confirmação (ACK). O emissor determina o seu número de seqüência e o receptor confirma o segmento usando como ACK o número de seqüência do emissor. Para a confiabilidade ser mantida, os segmentos são confirmados pelo receptor, indicando que recebeu um determinado número de bytes contíguos. Uma melhoria introduzida no TCP foi a possibilidade do receptor confirmar blocos fora da ordem esperada, o que é designado de selective ACK, ou apenas SACK.

A remontagem dos segmentos, de forma ordenada, é realizada através dos números de seqüência, com 32 bits, reiniciando a zero quando o valor máximo é ultrapassado, 231-1, tomando o valor da diferença. Dessa forma, a escolha do número de seqüência inicial torna-se necessária para a robustez do protocolo.

A técnica de checksum assegura a integridade do segmento e é parcialmente compensada com uso de CRC e outras testes de integridade no nível da camada abaixo da de transporte. As confirmações de recepção (ACK) servem também ao emissor para determinar as condições da rede. Com os temporizadores, o fluxo dos dados pode ser alterado tanto pelos emissores quanto pelos receptores, e, ainda, eventuais problemas de congestão podem ser contornados e, em alguns casos, o congestionamento da rede pode ser prevenido. Alguns mecanismos são adotados para se obter o máximo de desempenho da rede sem a congestionar. São exemplos: a janela deslizante e o algoritmo de início-lento.

O parâmetro janela, do cabeçalho TCP, permite indicar o espaço livre atual do receptor. Dessa maneira, o emissor fica sabendo que só terá em trânsito aquela quantidade de informação, aguardando pela confirmação (ACK) de um dos pacotes – que trará uma atualização da janela.

Como o tamanho do campo não pode ser expandido, os limites aparentes da janela variam entre 2 e 65535, o que é considerado pouco em redes com hardware de alto desempenho. Para contornar essa limitação, uma opção que permite obter múltiplos do valor da janela é usada, chamada de escala da janela (TCP window scale); este valor indica quantas vezes o valor da janela, de 16 bit, deve ser operado por deslocamento de bits (para a esquerda) para obter os múltiplos (pode variar entre 0 e 14). Com isto, é possível obter janelas de 1 gigabyte. O parâmetro de escala é definido unicamente durante o estabelecimento da ligação.

O encerramento da sessão TCP se dá em quatro fases, nas quais cada parte comunicante se responsabiliza pelo encerramento do seu lado na ligação. Quando um deles decide finalizar a sessão, este envia um pacote com a flag FIN ativada e deverá receber uma resposta ACK. Por sua vez, o outro lado da comunicação irá proceder da mesma forma, envia um FIN que deve ser respondido um ACK. Pode ser que um dos lados não encerre a sessão. Este caso é chamado de conexão semi-aberta. O lado que não encerrou a sessão pode continuar enviando informação pela conexão, mas o outro lado não.

DCCP – Datagram Congestion Control Protocol

O DCCP é um protocolo unicast e orientado à conexão, com fluxo de dados bidirecional. As conexões são realizadas de forma análoga às do TCP: com uso de handshake semelhante (three-way). Assim como o TCP, o DCCP é um protocolo da camada de transporte e é orientado a mensagens.

Muitas aplicações não requerem todas as vantagens do TCP, como confiabilidade, por exemplo, mas necessitam de controle de fluxo e congestionamento. Neste caso, as mesmas não usam o protocolo UDP (User Datagram Protocol) porque o mesmo não trata congestionamento – e implementar esta funcionalidade é um trabalho considerado difícil. Em virtude disso, surgiu o DCCP, que implementa mecanismos de controle de congestionamento na própria camada de transporte, evitando que o desenvolvedor se preocupe com a implementação desta tarefa complexa na camada de aplicação, provendo controle de congestionamento para fluxo de dados não confiável, evitando atrasos associados com mecanismos de TCP.

DCCP é muito útil para aplicações com restrições de tempo na entrega dos dados, que podem se tornar inúteis para os receptores se entrega confiável ordenada é utilizada juntamente com controle de congestionamento (TCP, por exemplo, pode possuir grandes atrasos em função disso). Tais aplicações incluem fluxos multimídia e aplicações de telefonia via Internet.

Em uma conexão TCP circulam ACKs e dados. ACKs informam o emissor se seus pacotes chegaram e se foram confirmados. DCCP possui a opção de números de seqüência com 48 bits, que correspondem à identificação do pacote (ao contrário de 1 bytem no TCP). Este tamanho grande para os números de seqüência é utilizado para prevenir ataques de injeção de resets DCCP na conexão.

No geral, DCCP provê: • Fluxo de dados (datagramas) não confiável;• Handshakes confiáveis para configuração de conexão;• Negociação confiável de opções;• Controle de congestão com notificação de congestionamento explícito (ECN);• Mecanismos ACK de comunicação de perda de pacotes e informação ECN;• Dois mecanismos de controle de congestionamento: TCP-like e TCP-Friendly

Rate Control (TFRC).

Cada conexão DCCP ocorre entre dois pontos (como no TCP). Como é um protocolo full-duplex, os dados podem fluir em ambos os sentidos ou em apenas um. É chamado de “half-connection” o fluxo de dados em uma direção, bem como o fluxo de ACKs correspondentes no sentido oposto. Cada “half-connection” tem seu controle de congestionamento gerenciado separadamente.

Durante o processo de estabelecimento da conexão, são negociados entre os dois hosts os mecanismos de controle de congestionamento e seus parâmetros. No estabelecimento da conexão, é gerado um fluxo não confiável de datagramas, com ACKs. Há, então, a negociação confiável de parâmetros, como checksum e mecanismo de controle de congestionamento, e a opção de informar ao emissor sobre os pacotes recebidos, marcados com ECN, corrompidos ou descartados no buffer do receptor. O

controle de congestionamento do protocolo requer que o receptor envie marcas de ECN ao emissor, sendo necessário que o receptor avise sobre todos os congestionamentos encontrados. Existe, também, um mecanismo que o servidor evite conexões encerradas ou tentativas de conexões não completamente estabelecidas.

O protocolo DCCP é baseado em fluxo de pacotes e nunca retransmite um datagrama, ao contrário de TCP que é baseado em fluxo de bytes e tem entrega confiável. Os números de seqüência se referem aos pacotes, não a bytes, e todo pacote enviado recebe um número de seqüência, permitindo ao receptor DCCP detectar perda de dados.

O mecanismo de controle de congestão pode ser escolhido. O CCID para uma conexão determina o quanto de informação ACK é necessário para a transmissão. No CCID 2 (TCP-like) é necessário um ACK para cada dois pacotes, e cada ACK deve declarar exatamente quais pacotes foram recebidos; no CCID 3 (TFRC) é necessário um ACK por RTT, e ACKs devem declarar no mínimo os tamanhos dos intervalos de perda recentes. Além disso, CCID 2 possui algumas semelhanças com o TCP Sack, no que diz respeito a seus mecanismos e variáveis utilizadas (baseado no controle do fluxo de janelas, por exemplo). Graças ao “Ack Ratio” que controla a proporção aproximada de pacotes de dados por ACK, há um pequeno atraso no comportamento do CCID 2. O CCID 2 é apropriado para aplicações que necessitam enviar a maior quantidade de dados no menor tempo possível. Já o CCID 3 é apropriado para aplicações que se adaptam melhor a mudanças sutis na largura de banda.

O CCID descreve a maneira como um sistema utilizando DCCP limita a taxa de transmissão de pacotes na rede e os valores iniciais de parâmetros da conexão. Por exemplo, o tamanho inicial da janela de transmissão ou com qual freqüência e como as informações de congestionamento para o transmissor são enviadas pelo receptor. Os CCIDs são negociados durante o estabelecimento da conexão, mas podem ser trocados também após esta fase, quando a conexão já estiver estabelecida. Como a característica de tráfego de uma conexão em uma direção pode ser totalmente diferente da do tráfego na direção contrária, é interessante que se tenha a possibilidade de escolha entre os algoritmos de controle de congestionamento. Dessa forma, determinados algoritmos podem ser mais apropriados para certos tipos de aplicação.

Simulações

As simulações foram realizadas no simulador Network Simulator 2 (NS 2). O NS 2 é um simulador discreto, orientado a eventos, focado em pesquisas de redes de computadores, que provê suporte à simulação de TCP, UDP, DCCP, roteamento e protocolos de multicast em redes cabeadas e sem fio. Além disso, o NS 2 possui código fonte aberto.

O NS 2 é escrito em C++ e em OTcl (Tcl orientado a objetos), permitindo velocidade de execução das simulações, com o C++ (bibliotecas em C++ são usadas para tratar eventos e elementos de rede), e velocidade na edição dos scripts, com a linguagem OTcl (Scripts OTcl são utilizados para descrever ambientes de simulação).

As principais vantagens do NS 2 são: possui suporte ao desenvolvimento de novos protocolos, possui um uso bastante difundido no meio acadêmico, possui gerador e editor de topologias e, ainda, possui um visualizador das simulações (NAM – Network Animator).

A simulação objetivou a comparação entre a vazão dos fluxos de dados no protocolo TCP Sack e no protocolo DCCP, com CCID 2 e CCID 3, ou seja, usou-se a métrica vazão dos fluxos para a comparação entre os protocolos. Para isto, foram necessários seis cenários, em virtude da especificação do projeto, na qual exigia-se que fosse simulado links entre os roteadores com 1Mbps, 2 Mbps e 10Mbps, tanto para o DCCP CCID 2 quanto para o DCCP CCID 3.

A topologia simulada foi a seguinte:

Para isto, foram criados seis arquivos, um para cada cenário, nos quais foram configurados os agentes de cada nó (TCP e DCCP), a topologia, os fluxos de dados (CBR, no caso de TCP Sack e DCCP CCID 2, e FTP, no caso de DCCP CCID 3), o tempo de simulação e os links entre os nós.

Como visto na topologia acima, o fluxo de dados entre x e z se dá através do protocolo TCP Sack. Já entre Y e W, o protocolo utilizado é o DCCP. Como falado, o link entre R1 e R2 variou com os seguintes valores: 1Mbps, 2 Mbps e 10Mbps (com RTT de 20ms). O link entre os hosts e os roteadores foi de 10 Mbps e 1ms de RTT. A capacidade máxima das filas foi considerada como sendo 500 pacotes, o tempo de simulação em todos os cenários foi de 900s e o tamanho dos pacotes foi definido como sendo de 512bytes. Para os fluxos de dados gerados, foram adotados 10Mbps, tanto para CBR quanto para FTP.

Resultados obtidos

Nesta seção são mostrados os resultados das simulações executadas, através dos gráficos gerados com estes dados, bem como uma breve explicação de cada resultado. Todos os gráficos a seguir apresentam as vazões dos fluxos gerados em cada protocolo de transporte, TCP e DCCP, durante as simulações.

O gráfico abaixo apresenta a vazão dos fluxos de dados gerados sendo transmitidos com o protocolo TCP, entre os nós x e z, e com o protocolo DCCP CCID 2, entre os nós y e w, com enlace de 1Mbps entre os roteadores. Percebe-se que a vazão do fluxo transmitido através do protocolo TCP foi maior que a do protocolo DCCP, CCID 2. Um possível motivo para isso é que o CCID 2 é semelhante ao TCP, tendo como principal diferença o fato do DCCP CCID 2 não retransmitir dados no caso de perda de pacotes. O CCID 2, como TCP, baseia-se no algoritmo de controle de fluxo baseado em janelas. Outra diferença que o CCID 2 apresenta em relação ao TCP é a presença de um mecanismo de controle de congestionamento de caminho reverso, que causa um certo atraso. Em virtude disso e do mecanismo que controla a proporção aproximada de pacotes de dados por ACK (ACK Ratio) a vazão neste cenário foi maior com o protocolo TCP, que com o protocolo DCCP CCID 2.

Resultado obtido do cenário: TCP x DCCP CCID 2 com link entre roteadores de 1Mbps

O gráfico abaixo exibe o resultado da simulação com o cenário que apresenta o link de 2Mbps entre os roteadores e utiliza o DCCP CCID 2 como protocolo entre y e w. A vazão dos fluxos de dados segue a mesma idéia do gráfico anterior: protocolo TCP entre x e z e protocolo DCCP CCID 2 entre y e w, com a modificação citada entre os roteadores (link de 2Mbps). Pode-se observar que aconteceu o mesmo: em virtude dos mecanismos de controle de congestionamento do CCID 2, citado na figura anterior, a vazão do fluxo de dados com o protocolo TCP foi maior que com o protocolo DCCP.

Resultado obtido do cenário: TCP x DCCP CCID 2 com link entre roteadores de 2Mbps

O gráfico seguinte mostra a vazão do fluxo de dados resultante da simulação realizada com link de 10Mbps entre os roteadores e CCID 2. Neste caso, percebe-se que aconteceu o contrário do que havia acontecido com os dois cenários anteriores: a vazão dos dados com o protocolo DCCP foi maior que a vazão com o protocolo TCP. Isto é o esperado, tendo em vista que o link entre os roteadores é bem maior agora e que o DCCP não retransmite pacotes, no caso de perda. Como o TCP tem mecanismo de confiabilidade, retransmissão, este perde mais tempo realizando esta tarefa, por isso a vazão do DCCP foi maior neste caso.

Resultado obtido do cenário: TCP x DCCP CCID 2 com link entre roteadores de 10Mbps

O resultado mostrado abaixo diz respeito à simulação do cenário com link de 1Mbps entre os roteadores e protocolo de transporte DCCP CCID 3 entre y e w. Como o CCID 3 não apresenta os mecanismos de congestionamento da mesma forma que o CCID 2, que apresentam um atraso significante em certos casos, graças ao não reenvio de pacotes (protocolo não confiável) no caso de perdas por parte do DCCP e graças aos mecanismos de controle de congestionamento “mais leves” do DCCP (em relação ao TCP), a vazão do mesmo foi maior que a do TCP.

Resultado obtido do cenário: TCP x DCCP CCID 3 com link entre roteadores de 1Mbps

O gráfico abaixo expõe o resultado da simulação do cenário com link de 2Mbps entre os roteadores e DCCP CCID 3 entre y e w. Da mesma maneira que o resultado exposto no gráfico anterior, percebe-se que, pelos mesmos motivos, a vazão dos fluxos de dados com o protocolo DCCP foi maior que a vazão com o protocolo TCP.

Resultado obtido do cenário: TCP x DCCP CCID 3 com link entre roteadores de 2Mbps

O gráfico a seguir expõe o resultado da simulação do cenário com link de 10Mbps entre os roteadores e protocolo de transporte DCCP CCID 3 entre y e w. Novamente, tem-se que a vazão foi maior no protocolo DCCP que no protocolo TCP, em virtude dos mecanismos de controle de congestionamento serem mais leves no DCCP e o CCID 3 não possuir mecanismos semelhantes ao CCID 2, que provocam certos atrasos.

Resultado obtido do cenário: TCP x DCCP CCID 3 com link entre roteadores de 10Mbps

Conclusão

Com este projeto foi possível perceber a diferença entre os dois protocolos de transporte estudados e verificar como ambos se comportam nas situações descritas para as simulações. Foi visto que, mesmo o DCCP não tendo mecanismo de confiabilidade, não reenviando pacotes, em determinadas situações o mesmo se comporta com uma vazão inferior à do TCP, dependendo de alguns parâmetros de rede e de qual algoritmo de controle de congestionamento é utilizado.

O mais importante é saber que, paralelamente ao renomado TCP, existem outros protocolos tão eficientes quanto este ou mais eficientes, e que, dependendo das aplicações, estes protocolos são mais indicados, em virtude de seu melhor desempenho.

Referências Bibliográficas

KOHLER, Eddie; HANDLEY, Mark; FLOYD, Sally. Designing DCCP: Congestion Control Without Reliability. SIGCOMM, 11-15/09/2006, Pisa, Itália.

TAKEUCHI, Shigeki; KOGA, Hiroyuki; IIDA, Katsuyoshi; KADOBAYASHI, Youki; YAMAGUCHI, Suguru. Performance Evaluations of DCCP for Bursty Traffic in Real-time Applications.

KOHLER, Eddie; FLOYD, Sally. Datagram Congestion Control Protocol (DCCP) Overview. ICIR, 09/07/2003.

SALES, Leandro Melo de. Avaliação Experimental do Protocolo DCCP para Transmissão de Conteúdos Multimídia em Redes Sem Fio 802.11g e na Internet. Dissertação de mestrado. Abril de 2008.

PADHYE, Jitendra; FLOYD, Sally; KOHLER, Eddie. Profile for DCCP Congestion Control ID 3: TFRC Congestion Control. ICIR, 23/10/2002.

Manual do NS 2, disponível em: http://www.isi.edu/nsnam/ns/ns-documentation.html (último acesso em 30/08/2008)

http://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol (último acesso em 28/08/2008)

http://en.wikipedia.org/wiki/Transmission_Control_Protocol (último acesso em 28/08/2008)