Fast DCCP: Uma variante do protocolo DCCP para redes de alta velocidade

Fast DCCP: Uma variante do protocolo DCCP para redes de

alta velocidade

Instituto de Computac¸˜ao – Universidade Estadual de Campinas Campinas, SP

{carlos,nfonseca}@ic.unicamp.br, [email protected]

Abstract. _{The Internet transport layer protocols, TCP and UDP, do not}

pro-vide efficient transport for multimedia streams. UDP is usually used for these application, due to its low overhead. A new transport layer protocol, called DCCP, was proposed to meet the demand of multimedia applications, aiming at replacing the UDP protocol. This paper will propose a variant for this protocol, called Fast DCCP, for operating efficiently on high-speed networks.

Resumo. _{Os protocolos da camada de transporte na Internet, TCP e UDP, n˜ao}

oferecem servic¸os para transmiss˜ao eficiente de fluxos multim´ıdia, por´em, este ´ultimo ´e adotado com maior freq¨uˆencia por essas aplicac¸˜oes. Uma proposta de um novo protocolo da camada de transporte, chamado DCCP, foi elaborada para atender a demanda das aplicac¸˜oes multim´ıdia e substituir o protocolo UDP. O presente artigo prop˜oe uma variante deste protocolo, chamada Fast DCCP, para operar de maneira eficiente em redes de alta velocidade.

1. Introduc¸˜ao

Nos ´ultimos anos, houve um aumento consider´avel do n´umero de aplicac¸˜oes multim´ıdia na Internet, que s˜ao sens´ıveis ao atraso e que requerem, de maneira geral, taxas de trans-miss˜ao m´ınima. ´E extremamente desafiador fornecer a qualidade de servic¸o necess´aria `a estas aplicac¸˜oes, utilizando o tipo de servic¸o Best Effort, apesar do aumento significa-tivo de banda nos enlaces da Internet. Os protocolos atualmente empregados na camada de transporte, Transmission Control Protocol (TCP) e User Datagram Protocol (UDP), s˜ao ineficientes na garantia de condic¸˜oes necess´arias para transmiss˜oes das aplicac¸˜oes multim´ıdia, por´em este ´ultimo tem sido adotado com mais freq¨uˆencia, uma vez que as aplicac¸˜oes multim´ıdia s˜ao sens´ıveis ao atraso.

O aumento da utilizac¸˜ao do protocolo UDP pelas aplicac¸ ˜oes multim´ıdia pode co-locar em risco o bom funcionamento da Internet, sobretudo em redes de alta velocidade, uma vez que este protocolo n˜ao efetua nenhum tipo de controle de congestionamento. Por outro lado, algumas funcionalidades do protocolo TCP, como por exemplo, o conceito de conex˜oes, s˜ao interessantes para alguns tipos de aplicac¸ ˜oes multim´ıdia. A proposta, da IETF de um novo protocolo para a camada de transporte, o Datagram Congestion Control

Protocol (DCCP) [Floyd et al. 2006b] oferece o estabelecimento de conex˜ao para envio

n˜ao confi´avel de fluxo de dados e controle de congestionamento. O protocolo fornece dois mecanismos distintos de controle de congestionamento, sendo ambos amig´aveis ao protocolo TCP, ou seja, visam garantir uma dispusta justa por recursos entre seus fluxos

e os fluxos deste protocolo. Um dos controles, o TCPLike, ´e similar ao controle de con-gestionamento implementado no TCP e o outro, o TCP-Friendly Rate Control (TFRC) [Floyd et al. 2006a] implementa controle baseado em taxas.

Uma avaliac¸˜ao do protocolo DCCP, quando este opera com o controle de con-gestionamento TFRC em redes de alta velocidade, foi realizada em [Froldi et al. 2010]. Avaliou-se o desempenho deste protocolo e identificou-se algumas limitac¸˜oes que o im-pedem de operar de maneira eficiente em tais redes, sendo a principal delas a falta de escalabilidade em func¸˜ao do aumento de banda passante.

O presente artigo introduz uma variante do protocolo DCCP para redes de alta velocidade, chamada Fast DCCP, que visa sanar alguns dos problemas apontados em [Froldi et al. 2010]. Utilizou-se simulac¸˜ao, tendo como ferramenta o simulador NS-2, bem como medic¸˜oes, utilizando o sistema operacional Linux. Diferentes cen´arios foram elaborados para a avaliac¸˜ao da escalabilidade, da convergˆencia, da justic¸a e da compa-tibilidade com o TCP-Reno. Todos os cen´arios seguem as recomendac¸˜oes para an´alise dos mecanismos de controle de congestionamento em novos protocolos propostas em [Floyd and Kohler 2006]. Constatou-se que o Fast DCCP foi bem-sucedido em sanar a deficiˆencia de escalabilidade em func¸˜ao do aumento de banda passante, sem degradar ou-tras m´etricas observadas no protocolo DCCP, tais como: justic¸a, escalabilidade em func¸˜ao do n´umero de conex˜oes e convergˆencia.

Este artigo est´a organizado da seguinte forma, a sec¸˜ao 2 descreve o protocolo DCCP e o mecanismo de controle de congestionamento TFRC. A sec¸˜ao 3 apresenta a va-riante do protocolo DCCP para redes de alta velocidade, o protocolo Fast DCCP e a sec¸˜ao 4 discute as propriedades avaliadas. A sec¸˜ao 5 apresenta os resultados dos experimentos realizados e a sec¸˜ao 6 deriva algumas conclus˜oes.

2. Protocolo DCCP

O protocolo DCCP foi concebido para fornecer funcionalidades necess´arias `as aplicac¸˜oes multim´ıdia na Internet, tais como streaming e voz sobre IP. O protocolo DCCP visa ofe-recer controle de congestionamento e reconhecimento da chegada de pacotes (ACK), `as aplicac¸˜oes que n˜ao toleram o overhead introduzido pela entrega confi´avel provida pelo protocolo TCP. As caracter´ısticas principais do protocolo DCCP s˜ao: fluxo de datagramas orientado `a conex˜ao e n˜ao confi´avel com confirmac¸˜ao de entrega, handshake confi´avel para estabelecimento e t´ermino da conex˜ao, negociac¸˜ao confi´avel de parˆametros a se-rem utilizados durante a conex˜ao e mecanismos de controle de congestionamento

TCP-Friendly, que incorporam o mecanismo Explicit Congestion Notification (ECN).

Os controles de congestionamento suportados pelo DCCP s˜ao definidos atrav´es de um CCID (Congestion Control Identifier) e podem ser identificados por um n´umero de 0 a 255. Os CCIDs definidos, inicialmente, para o DCCP, de acordo com [Floyd et al. 2006b], s˜ao: 0 – Reservado, 1 – Controle de congestionamento n˜ao espe-cificado baseado no usu´ario, 2 – Controle de congestionamento TCP-Like, 3 – Controle de congestionamento TFRC.

O controle de congestionamento TFRC (CCID 3) ´e recomendado para aplicac¸˜oes que precisam transmitir a taxas constantes, pois s˜ao sens´ıveis `a mudanc¸as abruptas na taxa de envio. Um exemplo de aplicac¸˜ao que utilizaria o CCID 3 ´e voz sobre IP em

tempo real. No TFRC, o receptor efetua medic¸˜oes de perdas de pacotes e retorna esta informac¸˜ao ao emissor que utiliza estas mensagens de retorno para medic¸˜ao do round-trip

time (RTT). As informac¸˜oes sobre perdas enviadas pelo receptor e o RTT estimado s˜ao

utilizados para atualizar a taxa de transmiss˜ao do emissor, calculada atrav´es da equac¸˜ao de vaz˜ao, que ´e uma vers˜ao simplificada da equac¸˜ao de throughput do TCP-Reno, definida por [Floyd et al. 2006a]:

X = s

R ∗ sqrt(2 ∗ b ∗ p/3) + (tRT O ∗ (3 ∗ sqrt(3 ∗ b ∗ p/8) ∗ p ∗ (1 + 32 ∗ p2₎₎₎ (1)

onde: X ´e a taxa de transmiss˜ao em bytes/segundo, s ´e o tamanho do pacote em bytes, R ´e o RTT em segundos, p ´e a taxa de ocorrˆencia de perdas, valor entre 0 e 1, que expressa o n´umero de eventos de perda em relac¸˜ao a frac¸˜ao de pacotes transmitidos, tRT O ´e o valor do timeout de retransmiss˜ao do TCP em segundos e b = 1 e representa o n´umero m´aximo de pacotes confirmados por um pacote de confirmac¸˜ao.

3. Fast DCCP

A variante do protocolo DCCP. chamada Fast DCCP, introduzida neste artigo, tem como objetivo melhorar as deficiˆencias do protocolo DCCP, reportadas em [Froldi et al. 2010], a fim de promover escalabilidade em func¸˜ao do aumento da capacidade de banda passante no enlace.

O protocolo Fast DCCP prop˜oe duas mudanc¸as no mecanismo de controle de congestionento TFRC, do protocolo DCCP. A primeira alterac¸˜ao ´e a inclus˜ao de um fator de correc¸˜ao no c´alculo da taxa de transmiss˜ao, que permite ao TFRC aumentar esta taxa de maneira mais eficiente. A segunda alterac¸˜ao trata da modificac¸˜ao da func¸˜ao de atualizac¸˜ao da taxa de transmiss˜ao do TFRC, quando perdas s˜ao detectadas.

O fator de correc¸˜ao proposto para o mecanismo TFRC do protocolo Fast DCCP ´e calculado atrav´es do uso de amostragens da variac¸˜ao de atraso, que s˜ao utilizadas para realizac¸˜ao do c´alculo da nova taxa de transmiss˜ao. O novo mecanismo proposto, em-bora seja distinto, foi inspirado em dois mecanismos existentes no protocolo Fast TCP, o estimador de banda e o mecanismo para o acr´escimo da janela de transmiss˜ao.

Conex˜oes do protocolo DCCP contabilizam o valor de duas vari´aveis: o atraso m´edio de propagac¸˜ao para a conex˜ao (R) e o atraso atual (Rsample), que considera o atraso de propagac¸˜ao verificado na ´ultima interac¸˜ao entre emissor e receptor. O c´alculo desses valores, definidos em [Floyd et al. 2006a], ´e realizado de acordo com as express˜oes abaixo:

Ri+1= (0.9 ∗ Ri) + (1–0.9) ∗ Rsample (2)

Rsample = (tnow–trecvdata)–tdelay (3)

ondetnow ´e o momento em que o pacote ´e recebido pelo emissor, trecvdata ´e o timestamp do ´ultimo pacote de dados recebido pelo receptor etdelay ´e o tempo decorrido

entre o recebimento do ´ultimo pacote e a gerac¸˜ao do pacote de confirmac¸˜ao observado no receptor.

O fator de correc¸˜ao da taxa de transmiss˜ao, denotado porα, proposto para o pro-tocolo Fast DCCP, considera a raz˜ao entre o atraso m´edio para a conex˜ao (R) e o atraso atual (Rsample), o que possibilita acr´escimos multiplicativos da taxa de transmiss˜ao, ao inv´es de aditivos como no DCCP, permitindo que se alcance maior escalabilidade em func¸˜ao do aumento da banda. Valores de α superiores a 1, indicam a existˆencia de re-cursos na rede, tendo em vista que o atraso de propagac¸˜ao atual (Rsample) ´e inferior ao atraso m´edio de propagac¸˜ao para a conex˜ao (R).

O fator de correc¸˜ao ´e utilizado para calcular um novo valor para a taxa de trans-miss˜ao (Xcorrigido) do protocolo Fast DCCP, atrav´es de:

Xcorrigido = ((X ∗ α) + X)); (4)

onde X ´e o valor atual da taxa de transmiss˜ao. De acordo com [Floyd et al. 2006a], o mecanismo TFRC do protocolo DCCP efetua o c´alculo da taxa de transmiss˜ao, quando n˜ao h´a ocorrˆencia de perdas, da seguinte maneira:

X = max(min(2 ∗ X, 2 ∗ Xrecv)), s/R); (5)

ondeXrecv ´e a taxa de transmiss˜ao informada pelo receptor e s ´e o pacote defi-nido para conex˜ao DCCP, conforme descrito em [Floyd et al. 2006a]. O valor da taxa de transmiss˜ao do protocolo Fast DCCP considera o valor m´aximo entre as taxas calculadas pelo TFRC do protocolo DCCP (2 ∗ X e 2 ∗ Xrecv) e a taxa calculada atrav´es do fator de correc¸˜ao (Xcorrigido), conforme a equac¸˜ao:

X = max(max(Xcorrigido, 2 ∗ X, 2 ∗ Xrecv), s/R); (6) Assim, sempre que houver disponibilidade de recursos na rede (α > 1), o valor para a taxa de transmiss˜ao calculada com o uso do fator de correc¸˜ao (Xcorrigido) ser´a su-perior aos demais valores das taxas calculados pelo TFRC, o que permite que o protocolo

Fast DCCP utilize de maneira eficiente os recursos dispon´ıveis.

A falta de escalabilidade do protocolo DCCP em func¸˜ao do aumento de banda nos enlaces reportada em [Froldi et al. 2010], al´em de evidenciar a necessidade de um estimador de banda para que se possa avaliar o quanto a taxa de transmiss˜ao pode crescer, permitiu tamb´em verificar que a capacidade de crescimento da taxa de transmiss˜ao do protocolo DCCP ´e significamente impactada pela ocorrˆencia de perdas na conex˜ao, pois sempre que uma perda ´e detectada o emissor DCCP reduz a sua taxa de transmiss˜ao de acordo com:

X = max(min(Xcalc, 2 ∗ Xrecv), s/tmbi); (7)

onde Xcalc ´e a taxa de transmiss˜ao calculada pela Equac¸˜ao 1 e s/tmbi

repre-senta um pacote (s) enviado a cada 64 segundos (valor da constante tmbi definido em

O outro aspecto determinante para a escalabilidade ´e a reac¸˜ao frente a ocorrˆencia de perdas. O mecanismo de controle de congestionamento TFRC foi concebido para ser amig´avel ao protocolo TCP-Reno, consequentemente, diminui, de maneira consider´avel, sua taxa de transmiss˜ao na existˆencia de congestionamento, indicada pela ocorrˆencia de perdas. Assim, espera-se que fluxos TCP-Reno e DCCP possam competir em igualdade de condic¸˜oes pelos recursos dispon´ıveis no enlace. Quando um protocolo opera em redes de alta velocidade, a reduc¸˜ao acentuada da taxa de transmiss˜ao leva a ineficiˆencia em se utilizar a banda dispon´ıvel dado o longo tempo necess´ario para se retornar o valor da taxa de transmiss˜ao no momento da perda.

A segunda alterac¸˜ao proposta para o mecanismo TFRC modifica o c´alculo da taxa de transmiss˜ao descrita na Equac¸˜ao 7, a fim de evitar reduc¸˜oes abruptas da taxa de trans-miss˜ao. O c´alculo da taxa de transmiss˜ao, proposto para o protocolo Fast DCCP, quando ocorrˆencias de perda s˜ao observadas, ´e definido por:

X = max(max(Xcalc, 2 ∗ Xrecv), s/tmbi); (8)

A taxa de transmiss˜ao, portanto, ser´a atualizada com o valor m´aximo e n˜ao com o valor m´ınimo, dentre os valores calculados, pelo TFRC, para nova taxa de transmiss˜ao (Xcalc ou 2 ∗ Xrecv). O novo mecanismo de controle de congestionamento dispon´ıvel no protocolo Fast DCCP, contendo as alterac¸˜oes descritas nesta sec¸˜ao, ser´a chamado de

Fast TFRC.

4. Propriedades Avaliadas

Para avaliar a eficiˆencia do protocolo Fast DCCP, quando este opera em redes de alta velo-cidade, m´etricas espec´ıficas foram medidas, tanto nos experimentos de simulac¸˜ao quanto nos de medic¸˜ao. Os resultados obtidos foram comparados com os resultados obtidos pelo protocolo DCCP original. S˜ao elas: escalabilidade, justic¸a, convergˆencia e compatibi-lidade com o protocolo TCP-Reno. A avaliac¸˜ao destas m´etricas s˜ao recomendadas em [Floyd and Kohler 2006]. A seguir uma descric¸˜ao de cada uma destas m´etricas e sua re-levˆancia.

A escalabilidade ´e definida como a capacidade do protocolo em se adaptar ao crescimento da disponibilidade de recusos de uma rede, sendo fundamental para um pro-tocolo operar nas redes de alta velocidade. Os experimentos avaliaram a escalabilidade em func¸˜ao da capacidade dispon´ıvel no enlace. Aumentou-se a capacidade de trans-miss˜ao dos enlaces e avaliou-se a habilidade do protocolo de utilizar, de forma eficiente, a banda dispon´ıvel. Os experimentos investigaram, tamb´em, a escalabilidade, em func¸˜ao do n´umero de conex˜oes; aumentou-se o n´umero de conex˜oes do protocolo e verificou-se a habilidade do protocolo de manter a utilizac¸˜ao do enlace est´avel e justa entre as conex˜oes. O crit´erio de justic¸a pode ser avaliado pela capacidade do protocolo em garan-tir divis˜ao igualit´aria de banda passante entre as conex˜oes, pelo ajuste indireto da taxa de transmiss˜ao. ´E importante que um protocolo apresente justic¸a para garantir que as conex˜oes que compartilham o enlace possam aumentar a sua taxa de transmiss˜ao de ma-neira eficiente. Quantifica-se o grau de justic¸a atrav´es do coeficiente Jain Fairness Index [Jain 1991], que varia entre 0 e 1. Valores mais pr´oximos de 0 indicam injustic¸a e valores mais pr´oximos de 1 um sistema justo.

A convergˆencia `a justic¸a ´e o tempo necess´ario para que se obtenha divis˜ao igua-lit´aria da banda passante. ´E importante que um protocolo apresente convergˆencia para garantir que conex˜oes recentemente iniciadas possam competir de maneira justa, pela banda passante, com conex˜oes inciadas h´a mais tempo.

A compatibilidade com o TCP-Reno ´e definida como a capacidade dos fluxos de dados do protocolo coexistirem de maneira justa com os fluxos de dados do protocolo TCP, garantindo que ambos os fluxos possam disputar de maneira equilibrada o uso da banda passante.

5. Avaliac¸˜ao de desempenho

Os cen´arios e m´etricas utilizados para avaliac¸˜ao do protocolo Fast DCCP em redes de alta velocidade foram derivados a partir do proposto em [Floyd and Kohler 2006]. Todos os experimentos utilizam a topologia Dumbbell (Figura 1), que cont´em um ´unico enlace gargalo constitu´ıdo por dois roteadores por onde passam conex˜oes. O n´umero de conex˜oes varia de acordo com os experimentos realizados.

Para os experimentos de simulac¸˜ao foi utilizado o simulador de redes NS-2 [Network Simulator 2010], vers˜ao 2.31. Para os experimentos de medic¸˜ao foi utilizado o sistema operacional Linux, com o kernel da vers˜ao 2.6.20. O m´odulo do DCCP contido no NS-2 e a implementac¸˜ao do protocolo DCCP contida no sistema operacional Linux foram alterados, para corresponder a variante proposta, o protocolo Fast DCCP.

Para os experimentos de simulac¸˜ao com o NS-2, os dois roteadores utilizam geren-ciamento de fila droptail e possuem buffer de 2500 pacotes, valor este semelhante ao ta-manho de buffers em roteadores reais [Wei et al. 2005]. Para evitar impactos relacionados a sincronizac¸˜ao das conex˜oes nas simulac¸˜oes, os instantes dos in´ıcios das transmiss˜oes e os atrasos de propagac¸˜ao para cada uma das conex˜oes foram gerados aleatoriamente. Os instantes dos in´ıcios variaram entre 1 e 10s e os atrasos de propagac¸˜ao entre 5 e 15ms. Tr´afego background foi introduzido, visando refletir composic¸˜ao de tr´afego em ambiente de redes reais. O tr´afego background utiliza 20%, 50% ou 80% da capacidade do enlace de gargalo, no sentido reverso, de acordo com a distribuic¸˜ao: 20% de tr´afego UDP, 56% de tr´afego Web e 24% de tr´afego FTP. O tr´afego utilizado pelas conex˜oes foi do tipo CBR, com a taxa de transmiss˜ao de cada conex˜ao ajustada para que a mesma fac¸a uso de toda a capacidade de transmiss˜ao do enlace de gargalo estipulado no cen´ario do experimento.

Para os experimentos de medic¸˜ao, foram utilizados dois computadores com inter-faces ethernet com capacidade de 1Gbps, interligados atrav´es de um switch router com capacidade de 1Gbps por porta, sendo que cada uma das portas do switch estava com uma rota est´atica habilitada, emulando dois roteadores, j´a que as portas possuem um pro-cessador de pacotes e filas independentes. Todas as m´etricas de distribuic¸˜ao de tr´afego

background e limitac¸˜oes da capacidade do enlace f´ısico foram obtidas atrav´es do uso da

ferramenta tc, Traffic Control [Traffic Control HOWTO 2010], e para o envio de dados das conex˜oes Fast DCCP e TCP foi utilizado a ferramenta Iperf [Iperf 2010], sempre com transmiss˜ao de tr´afego CBR, com tempos para os instantes dos in´ıcios variando entre 1 e 10s.

Os gr´aficos apresentados mostram o valor m´edio obtido `a partir da execuc¸˜ao de 6 replicac¸˜oes para cada experimento. Para o c´alculo do intervalo de confianc¸a, foram utili-zados o m´etodo de replicac¸˜oes independente com n´ıvel de confianc¸a de 95%. O tempo de

Figura 1. Topologia Dumbbell

simulac¸˜ao de todos os experimentos foi de 600s. Os resultados da avaliac¸˜ao do protocolo DCCP, obtidos anteriormente em [Froldi et al. 2010] ser˜ao comentados, para que se possa comparar com os da avaliac¸˜ao do protocolo Fast DCCP.

Escalabilidade

Para avaliar a escalabilidade do protocolo Fast DCCP foram elaborados dois cen´arios dis-tintos: um para avaliar a escalabilidade em func¸˜ao do aumento da banda passante dos enlaces e outro em func¸˜ao do n´umero de conex˜oes. Para avaliar a escalabilidade em func¸˜ao da capacidade de transmiss˜ao do enlace de gargalo, variou-se a capacidade no se-guinte conjunto: [155Mbps, 622Mbps, 1Gbps]. O atraso do enlace foi fixado em 100ms e o n´umero de conex˜oes Fast DCCP utilizado foi 16. A Figura 2 e a Figura 3 apresentam, respectivamente, os resultados obtidos para os experimentos simulados e de medic¸˜ao. Em ambos os gr´aficos pode-se perceber um comportamento semelhante. As 16 conex˜oes Fast DCCP utilizam eficientemente o enlace (utilizac¸˜ao superior a 0.9) para todas as capacida-des de enlaces avaliadas. Analisando os resultados obtidos para a avaliac¸˜ao do protocolo DCCP em [Froldi et al. 2010], pode-se observar que a medida que a capacidade do en-lace aumenta, a utilizac¸˜ao ´e reduzida de maneira significativa, chegando a ser 0.6, para a capacidade de 1Gbps nos experimentos de medic¸˜ao, enquanto que para o protocolo Fast

DCCP esta utilizac¸˜ao ´e superior a 0.9 em todos os cen´arios. Pode-se concluir que o

proto-colo Fast DCCP ´e escal´avel em func¸˜ao do aumento de disponibilidade de banda. O fator de correc¸˜ao para o c´alculo da taxa de transmiss˜ao empregado pelo mecanismo Fast TFRC do Fast DCCP permite que a banda dispon´ıvel seja utilizada de maneira eficiente.

Para avaliar a escalabilidade em func¸˜ao do n´umero de conex˜oes, foram re-alizados experimentos com o n´umero de conex˜oes Fast DCCP variando entre 2 e 32 (21_{, 2}2_{, 2}3_{, ..., 2}4

), para os experimentos de medic¸˜ao, e variando entre 2 e 256 (21_{, 2}2_{, 2}3_{, ..., 2}8

), para os experimentos de simulac¸˜ao. A diferenc¸a na variac¸˜ao do n´umero de conex˜oes entre os experimentos deve-se `as limitac¸˜oes de hardware presente nos dispo-sitivos utilizados para realizac¸˜ao dos experimentos de medic¸˜ao. A capacidade de trans-miss˜ao do enlace foi fixado em 1Gbps e o atraso de propagac¸˜ao em 100ms. A Figura 4 e a Figura 5 apresentam, respectivamente, os resultados da avaliac¸˜ao da escalabilidade em func¸˜ao da variac¸˜ao do n´umero de conex˜oes, para os experimentos de simulac¸˜ao e de medic¸˜ao. Nota-se que na medida que o n´umero de conex˜oes aumenta, at´e 256, nos

0.2 0.4 0.6 0.8 1 155 622 1000 Utilização do enlace (%) Capacidade do enlace (Mbps)

Vazão dos fluxos Fast DCCP/NS−2 com carga de 0.2 Vazão dos fluxos Fast DCCP/NS−2 com carga de 0.5 Vazão dos fluxos Fast DCCP/NS−2 com carga de 0.8

Figura 2. Utilizac¸ ˜ao do enlace em func¸ ˜ao da variac¸ ˜ao da banda (NS-2)

0.2 0.4 0.6 0.8 1 155 622 1000 Utilização do enlace (%) Capacidade do enlace (Mbps)

Vazão dos fluxos Fast DCCP/Linux com carga de 0.2 Vazão dos fluxos Fast DCCP/Linux com carga de 0.5 Vazão dos fluxos Fast DCCP/Linux com carga de 0.8

Figura 3. Utilizac¸ ˜ao do enlace em func¸ ˜ao da variac¸ ˜ao da banda (Linux)

rimentos de simulac¸˜ao, a utilizac¸˜ao do enlace permanece est´avel e o tr´afego background implica em apenas mudanc¸as discretas na utilizac¸˜ao. Analisando os resultados obtidos para a avaliac¸˜ao do protocolo DCCP em [Froldi et al. 2010], nota-se que valores seme-lhantes aos do protocolo Fast DCCP foram obtidos, no que diz respeito a manutenc¸˜ao da utilizac¸˜ao do enlace `a medida que o n´umero de conex˜oes aumenta. A ´unica diferenc¸a que se nota entre os experimentos do protocolo DCCP e o protocolo emphFast DCCP, ´e que para este ´ultimo a utilizac¸˜ao do enlace observada ´e superior. O protocolo Fast DCCP opera de maneira escal´avel e eficiente em relac¸˜ao ao aumento do n´umero de conex˜oes, demonstrando que o mecanismo de controle de congestionamento empregado pelo Fast

TFRC garante a escalabilidade em func¸˜ao do n´umero de conex˜oes. Justic¸a

Para avaliar a justic¸a do Fast DCCP foram definidos dois cen´arios de simulac¸˜ao, ambos com 4 conex˜oes Fast DCCP transmitindo no enlace de gargalo, atraso de propagac¸˜ao de 100ms e capacidade do enlace de 1Gbps. No primeiro cen´ario, os fluxos Fast DCCP s˜ao iniciados, no mesmo instante de tempo (no instante 1s), enquanto que no segundo cen´ario

os fluxos Fast DCCP s˜ao iniciados, em instantes de tempo distintos (aleat´oriamente entre 1s e 10s).

A Figura 6 apresenta os resultados da avaliac¸˜ao de justic¸a para o primeiro cen´ario proposto, tanto para os experimentos de simulac¸˜ao quanto para os de medic¸˜ao. Nota-se, em ambos os casos, independentemente da intensidade do tr´afego background os valo-res do Jain Fairness Index ficaram pr´oximos a 0.9, o que indica que o protocolo produz justic¸a, ou seja, o Fast DCCP provˆe distribuic¸˜ao de banda equilibrada entre os fluxos que competem pelo enlace. A Figura 7 apresenta os resultados da avaliac¸˜ao de justic¸a para o segundo cen´ario, tanto para os experimentos de simulac¸˜ao quanto os de medic¸˜ao. Os valores s˜ao similares aos obtidos no cen´ario anterior, reforc¸ando a propriedade de justic¸a existente no protocolo. Analisando os resultados obtidos para a avaliac¸˜ao do protocolo DCCP em [Froldi et al. 2010], pode-se observar semelhanc¸a entre estes gr´aficos e os ob-tidos na avaliac¸˜ao do protocolo Fast DCCP, indicando que o Fast DCCP manteve as propriedades de justic¸a observadas no protocolo DCCP.

Convergˆencia

Para avaliar a convergˆencia do protocolo Fast DCCP, foram realizados experimentos com a seguinte configurac¸˜ao: enlace de gargalo fixado em 1Gbps, duas conex˜oes Fast DCCP, o atraso de propagac¸˜ao no enlace de gargalo em 100ms. A segunda conex˜ao Fast DCCP inicia a transmiss˜ao no instante 50s, tempo suficiente para a primeira conex˜ao alocar toda a banda dispon´ıvel do enlace de gargalo. A Figura 8 apresenta os resultados da avaliac¸˜ao da convergˆencia, tanto para os experimentos de simulac¸˜ao quanto para os de medic¸˜ao, para diferentes intensidades de tr´afego background. O tempo de convergˆencia ´e alto, em ambos os casos, apresentando valores entre 100s e 135s, que s˜ao, tipicamente, muito superiores ao tempo de durac¸˜ao m´edio de uma conex˜ao na Internet. Quando comparamos estes re-sultados com os rere-sultados obtidos na avaliac¸˜ao do protocolo DCCP [Froldi et al. 2010], nota-se valores similares no tempo de convergˆencia, que para o protocolo DCCP variam entre 90s e 120s. Pode-se dizer que o mecanismo de controle de congestionamento im-plementado pelo Fast TFRC, mesmo produzindo altos graus de justic¸a, n˜ao consegue prover uma resposta r´apida a divis˜ao igualit´aria da banda da rede entre fluxos que com-petem pelo enlace. Enfatiza-se que estudos anteriores, descritos em [Bansal et al. 2001] e [Vojnovic and Boudec 2003], apontam o problema do tempo de resposta alto do meca-nismo de congestionamento provido pelo TFRC. A variante do protocolo DCCP, o pro-tocolo Fast DCCP, apresenta as mesmas deficiˆencias, uma vez que seu mecanismo de controle de congestionamento, o Fast TFRC, ´e uma variante do mecanismo TFRC. Nota-se que os valores do tempo de convergˆencia obNota-servados para o protocolo Fast DCCP s˜ao, em m´edia, cerca de 7% maiores do que os valores observados para o protocolo DCCP. Isto se deve ao fato da variante do TFRC, chamada Fast TFRC, presente no protocolo

Fast DCCP possuir um mecanismo mais agressivo para aumento da taxa de transmiss˜ao

e um mecanismo mais tolerante para diminuic¸˜ao da taxa de transmiss˜ao.

Compatibilidade com o TCP-Reno

Para avaliar a compatibilidade do protocolo Fast DCCP com o protocolo TCP-Reno, fo-ram realizados experimentos com dois cen´arios distintos. Em um deles, dois fluxos TCP-Reno, transmitindo tr´afego FTP competem pela banda do enlace de gargalo e no outro um fluxo Fast DCCP e um fluxo TCP-Reno, com o mesmo tr´afego FTP do experimento

Tr´afego Background (%)

0.2 0.5 0.8

Utilizac¸˜ao do enlace (%) TCP-1 0.0152 0.0124 0.0061 TCP-2 0.0022 0.0017 0.0009

Tabela 1. Taxa de utilizac¸ ˜ao obtida pelos fluxos TCP (NS-2)

Tr´afego Background (%)

0.2 0.5 0.8

Utilizac¸˜ao do enlace (%) TCP-1 0.3120 0.2210 0.1830 TCP-2 0.0820 0.0545 0.0433

Tabela 2. Taxa de utilizac¸ ˜ao obtida pelos fluxos TCP (Linux)

anterior, competem pelo enlace de gargalo. A capacidade do enlace usada foi 1Gbps, o tempo de propagac¸˜ao foi de 10ms. O objetivo destes experimentos ´e avaliar se o TCP-Reno obt´em a mesma banda do enlace que seria obtida se o mesmo n˜ao estivesse con-correndo com o protocolo Fast DCCP. Na Tabela 1, s˜ao apresentados os resultados da avaliac¸˜ao de compatibilidade do Fast DCCP com o TCP-Reno, derivados nos experimen-tos de simulac¸˜ao. A utilizac¸˜ao do enlace para TCP-1 apresenta os valores obtidos pelo fluxo TCP, quando este concorre com outro fluxo TCP, enquanto que os resultados TCP-2 apresentam os valores obtidos pelo fluxo TCP, quando este concorre com um fluxo Fast

DCCP. Os diferentes valores de utilizac¸˜ao observadas em ambos os fluxos TCP sugerem

a incompatibilidade entre o protocolo Fast DCCP com o protocolo TCP-Reno, uma vez que o fluxo TCP-2 obt´em uma utilizac¸˜ao inferior a obtida pelo fluxo TCP-1.

Na Tabela 2, s˜ao apresentados os resultados da avaliac¸˜ao de compatibilidade do

Fast DCCP com o TCP-Reno, para os experimentos de medic¸˜ao. A utilizac¸˜ao do enlace

para TCP-1 apresenta os valores obtidos pelo fluxo TCP, quando este concorre com outro fluxo TCP, enquanto que os resultados TCP-2 apresentam os valores obtidos pelo fluxo TCP, quando este concorre com um fluxo Fast DCCP. Os diferentes valores de utilizac¸˜ao, sugerem a incompatibilidade entre o protocolo Fast DCCP com o protocolo TCP-Reno, dado que a utilizac¸˜ao do fluxo TCP-2 ´e inferior a obtida pelo fluxo TCP-1.

Analisando os resultados obtidos para a avaliac¸˜ao do protocolo DCCP em [Froldi et al. 2010], pode-se observar valores similares para a avaliac¸˜ao de compatibi-lidade entre o protocolo DCCP e o protocolo TCP-Reno. Nota-se a mesma incompa-tibilidade entre os fluxos de ambos os protocolos. Tal incompaincompa-tibilidade j´a havia sido descrita em [Rhee and Xu 2007]. Nota-se, no entanto, que a incompatibilidade entre o protocolo TCP-Reno e o protocolo Fast DCCP tornou-se mais acentuada, uma vez que os mecanismos para crescimento da taxa de banda deste protocolo s˜ao mais agressivos do que os mecanismos empregados pelo protocolo DCCP. Vale ressaltar que outros pro-tocolos para redes de alta velocidade, como por exemplo Fast TCP, apresentam incom-patibilidades similares quando seus fluxos disputam pelos recursos junto com fluxos do protocolo TCP-Reno, conforme relatado em [Jamal and Sultan 2008], [Li et al. 2007] e [Hatano et al. 2007].

Resumo dos resultados encontrados

Os resultados da avaliac¸˜ao de escalabilidade em func¸˜ao da variac¸˜ao da capacidade da banda do enlace apontam para a eficiˆencia do protocolo Fast DCCP em obter o uso efi-ciente dos recursos dispon´ıveis no enlace gargalo. Os resultados da avaliac¸˜ao de escala-bilidade em func¸˜ao do n´umero de conex˜oes demonstram que o protocolo Fast DCCP ´e eficiente na manutenc¸˜ao da justic¸a entre fluxos que competem pelo enlace de gargalo, em func¸˜ao do n´umero de fluxos. Os resultados da avaliac¸˜ao de convergˆencia indicam que o protocolo Fast DCCP, a exemplo do protocolo DCCP, possui convergˆencia lenta, para um estado de equil´ıbrio e justic¸a entre fluxos que disputam o enlace de gargalo, com valores, em m´edia, pr´oximos a 115s.

Os resultados da avaliac¸˜ao de compatibilidade entre os protocolos Fast DCCP e TCP-Reno indicam o desbalanceamento nas taxas de transmiss˜ao obtidas pelos fluxos de ambos os protocolos que disputam o enlace de gargalo. O desbalanceamento j´a ha-via sido reportado em [Froldi et al. 2010], quando fluxos DCCP competiam com fluxos TCP-Reno, por´em a intensidade do desbalanceamento ficou mais acentuada quando da utilizac¸˜ao do protocolo Fast DCCP, pois este emprega mecanismos mais agressivos para aumento da taxa de transmiss˜ao.

Os resultados da avaliac¸˜ao de justic¸a demonstram a eficiˆencia do protocolo Fast

DCCP em garantir que diferentes fluxos Fast DCCP possam competir, de maneira

equili-brada e justa, pelos recursos do enlace de gargalo.

6. Conclus˜ao

Com o resultado da avaliac¸˜ao de desempenho foi poss´ıvel comprovar a eficiˆencia do pro-tocolo Fast DCCP em resolver a limitac¸˜ao de escalabilidade em func¸˜ao do aumento de banda dos enlaces, caracter´ıstica mandat´oria para o sucesso do protocolo em redes de alta velocidade. Fica evidente que o mecanismo que estima banda, baseado nos tempos de atraso amostrados em um conex˜ao Fast DCCP vigente, contribui para o uso mais efici-ente do enlace.

Para acelerar a convergˆencia, ´e necess´ario avaliar de maneira mais detalhada as deficiˆencias descritas em [Bansal et al. 2001] e [Vojnovic and Boudec 2003], a fim de se propor melhorias no mecanismo Fast TFRC, adotado no Fast DCCP.

Como trabalho futuro sugere-se investigar com mais detalhes os pontos descritos acima, de forma a avaliar potenciais alterac¸˜oes no protocolo Fast DCCP.

Referˆencias

Bansal, D., Balakrishnan, H., Floyd, S., and Shenker, S. (2001). Dynamic behavior of slowly-responsive congestion control algorithms. In Proceedings of ACM

SIG-COMM’01, pages 263–274, San Diego,CA.

Floyd, S., Handley, M., Padhye, J., and Widmer, J. (2006a). Tcp friendly rate control (tfrc): Protocol specification. In RFC 3448.

Floyd, S. and Kohler, E. (2006). Tools for the evaluation of simulation and testbed scena-rios. In Internet Draft: draft-irtf-tmrg-tools-05.

Floyd, S., Kohler, E., and Handley, M. (2006b). Designing dccp: Congestion control without reliability. In Proceedings of ACM SIGCOMM’06, pages 27–38, Pisa, It´alia.

Froldi, C., Fonseca, N., and Papotti, C. (2010). Avaliac¸˜ao de desempenho do protocolo dccp para redes de alta velocidade. In Anais do Wperformance 2010, pages 1831–1844, Belo Horizonte, Brasil.

Hatano, T., Shigeno, H., and Okada, K. (2007). Tcp-friendly congestion control for highs-peed network. In Proceedings of IEEE SAINT’07, pages 1–10.

Iperf (2010). http://www.noc.ucf.edu/tools/iperf.

Jain, R. (1991). The Art of Computer Systems Performance Analysis: Techniques for

Experimental Design, Measurement, Simulation and Modeling. John Wiley & Sons.

Jamal, H. and Sultan, K. (2008). Performance analysis of tcp congestion control algo-rithms. In INTERNATIONAL JOURNAL OF COMPUTERS AND

COMMUNICATI-ONS, pages 30–38.

Li, Y., Leith, D., and Shorten, R. (2007). Experimental evaluation of tcp protocols for high-speed networks. In ACM TRANSACTIONS ON NETWORKING, Vol. 15, pages 1109–1122.

Network Simulator (2010). http://www.isi.edu/nsnam/ns.

Rhee, I. and Xu, L. (2007). Limitations of equation-based congestion control. IEEE

Transactions on Network, 15(4):852–865.

Traffic Control HOWTO (2010). http://tldp.org/howto/traffic-control-howto/index.html. Vojnovic, M. and Boudec, J. L. (2003). On the long run behavior of equation-based rate

control. In Proceedings of ACM SIGCOMM’02, pages 103–116.

Wei, D. X., Cao, P., and Low, S. H. (2005). Time for a tcp benchmark suite? (http://www.cs.caltech.edu/ weixl/research/technicals/benchmark/summary.ps).

0.2 0.4 0.6 0.8 1 2 4 8 16 32 64 128 256 Utilização do enlace (%) Número de Conexões

Vazão dos fluxos Fast DCCP/NS−2 com carga de 0.2 Vazão dos fluxos Fast DCCP/NS−2 com carga de 0.5 Vazão dos fluxos Fast DCCP/NS−2 com carga de 0.8

Figura 4. Utilizac¸ ˜ao do enlace em func¸ ˜ao do n ´umero de conex ˜oes (NS-2)

0.2 0.4 0.6 0.8 1 2 4 8 16 32 Utilização do enlace (%) Número de Conexões

Vazão dos fluxos Fast DCCP/Linux com carga de 0.2 Vazão dos fluxos Fast DCCP/Linux com carga de 0.5 Vazão dos fluxos Fast DCCP/Linux com carga de 0.8

Figura 5. Utilizac¸ ˜ao do enlace em func¸ ˜ao do n ´umero de conex ˜oes (Linux)

0.6 0.8 0.9 1 20 50 80 Jain Index Carga do enlace (%) Fast DCCP/Linux Fast DCCP/NS−2

0.6 0.8 0.9 1 20 50 80 Jain Index Carga do enlace (%) Fast DCCP/Linux Fast DCCP/NS−2

Figura 7. Segundo Cen ´ario de Justic¸a

20 40 60 80 100 120 140 150 20 50 80 Tempo (s) Carga do enlace (%) Fast DCCP/Linux Fast DCCP/NS−2