Referências Bibliográficas
[1] MORAES, L. F. M. Modelos de Fontes de Tráfego para RDSI-FL, Relatório Técnico - RAVEL/UFRJ, 1996. Disponível em http://www.ravel.ufrj.br Acesso em 3 jul. 2002.
[2] NAGLE, J. On Packet Switches with Infinitive Storage, IEEE Tran-sactions on Communications, v. 35, p. 435-438, 1987.
[3] BRADEN, B. et al. RFC 1633: Integrated Services in the Internet Architecture:An Overview. Disponível em http://www.ietf.org/rfc/rfc1633.txt. Acesso em 3 jul. 2002.
[4] BLAKE, S. et al. RFC 2475: An Architecture for Differentiated Service. Disponível em http://www.ietf.org/rfc/rfc2475.txt. Acesso em 3 jul. 2002.
[5] BLAKE, S. et al. RFC 2474: Definition of the Differentiated Ser-vices Field (DS Field) in the IPv4 and IPv6 Headers. Disponível em http://www.ietf.org/rfc/rfc2474.txt. Acesso em 3 jul. 2002.
[6] TOBAGI, F. Service Differentiation in the Internet to Support Multimedia Traffic, Relatório Técnico, Stanford University, CA. Dispo-nível em http://alexandria.stanford.edu/papers/tobagi-iwdc.pdf. Acesso em 3 jul. 2002.
[7] INTERNATIONAL TELECOMMUNICATION UNION TELECOMMU-NICATION SECTOR (ITU-T). Recommendations. Disponível em http://www.itu.int/ITU-T/. Acesso em 3 jul. 2002.
[8] PAULO, G.; VAZ, S. Avaliação por Simulação dos Mecanismos de Controle de Congestionamento do TCP, Relatório Técnico -GTA/UFRJ, ago. 2000. Disponível em http://www.gta.ufrj.br. Acesso em 3 jul. 2002.
[9] BRADEN, R. et al. RFC 2205: Resource Reservation Protocol (RSVP). Disponível em http://www.ietf.org/rfc/rfc2205.txt. Acesso em 3 jul. 2002.
[10] PARTRIDGE, C. et al. RFC 2212: Specification of Guaranteed Quality of Service. Disponível em http://www.ietf.org/rfc/rfc2212.txt. Acesso em 3 jul. 2002.
[11] WROCLAWSKI, J. RFC 2211: Specification of the Controlled-Load Network Element Service. Disponível em http://www.ietf.org/rfc/rfc2211.txt. Acesso em 3 jul. 2002.
[12] HEINANEN, J. et al. RFC 2697: A Single Rate Three Color Mar-ker. Disponível em http://www.ietf.org/rfc/rfc2697.txt. Acesso em 3 jul. 2002.
[13] HEINANEN, J. et al. RFC 2698: A Two Rate Three Color Marker. Disponível em http://www.ietf.org/rfc/rfc2698.txt. Acesso em 3 jul. 2002. [14] HEINANEN, J. et al. RFC 2859: A Time Sliding Win-dow Three Colour Marker (TSWTCM). Disponível em http://www.ietf.org/rfc/rfc2859.txt. Acesso em 3 jul. 2002.
[15] JACOBSON, V. et al. RFC 2598: An Expedited Forwarding PHB. Disponível em http://www.ietf.org/rfc/rfc2598.txt. Acesso em 3 jul. 2002. [16] HEINANEN, J. et al. RFC 2597: Assured Forwarding PHB Group. Disponível em http://www.ietf.org/rfc/rfc2597.txt. Acesso em 3 jul. 2002. [17] MAO, J.; MOH, W.; WEI, B. PQWRR Scheduling Algorithm in
Supporting of Diffserv, IEEE GLOBECOM, nov. 2001.
107
[18] GALLARDO, J. R.; MAKRAKIS, D. Dynamic Predictive Weighted Fair Queuing for Differentiated Services, IEEE GLOBECOM, nov. 2001.
[19] FERRARI, T.; PAU, G.; RAFFAELLI, C. Measurement Based Analysis of Delay in Priority Queuing, IEEE GLOBECOM, nov. 2001.
[20] SAHU, S.; TOWSLEY, D.; KUROSE, J. A Quantitative Study of Differentiated Services for the Internet, Journal of Comunications and Networks, v. 2, n. 2 , jun. 2000.
[21] MAY, M.; BOLOT, J.; JEAN-MARIE, A.; DIOT, C. Simple Perfor-mance of Differentiated Services Schemes for the Internet, IEEE Infocom, p. 1385-1394, mar. 1999.
[22] MATHIS, M. The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm, Computer Communication Review, v. 27(3), jul. 1997.
[23] SAHU, S. et al. .On Achievable Service Differentiation with Token Bucket Marking for TCP, Proceedings of ACM SIGMETRICS’00, jun. 2000.
[24] PADHYE, J. et al. A Stochastic Model of TCP Reno Congestion Avoidance and Control, UMASS, Relatório Técnico, mai. 1998. Dispo-nível em ftp://gaia.cs.umass.edu/pub/Padhey99-markov.ps. Acesso em 3 jul. 2002.
[25] BAINES, B. et al. Using TCP Models to Understand Bandwidth Assurance in a Differentiated Services Network, Computing Tech-nology Labs-Nortel Networks, Relatório Técnico, jul. 2000.
[26] CLARK, D.; FANG, W. Explicit Allocation of Best-Effort Packet Delivery Service, IEEE/ACM Transactions on Networking, v. 6, n. 4, p. 362-373 ago. 1998.
[27] PIEDA, P. Bandwith Assurance Issues for TCP Flows in a Dif-ferentiated Services Network, Proceedings of GLOBECOM’99, dez. 1999.
[28] UCLA, CA .Network Simulator ns-2. Disponível em http://www-mash.cs.berkeley.edu/ns. Acesso em 3 jul. 2002.
[29] PIEDA, P. et al. A Network Simulator: Differentiated Services Implementation, Open IP, Nortel Networks, jul. 2000.
[30] MATHIAS, F. R. Avaliação de Desempenho de Mecanismos de Controle de Tráfego em Redes com Serviços Diferenciados, Dis-sertação de Mestrado apresentada ao Departamento de Engenharia Elé-trica da PUC-RJ, abr. 2002.
[31] KARAM, M. J.; TOBAGI, F. A. On Traffic Types and Service Clas-ses in the Internet, Proceedings of GLOBCOM’00, dez. 2000.
[32] FLOYD, S.; JACOBSON, V. Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, v. 1, N.4, p.397-413, ago. 1993.
[33] Technical Specification from Cisco Systems. Distributed Weighted Random Early Detection, Disponível em http://www.cisco.com/univercd/cc/td/doc/product/software. Acesso em 3 jul. 2002.
[34] WROCLAWSKI, J. et al. RFC 2216: Network Ele-ment Service Specification Template. Disponível em http://www.ietf.org/rfc/rfc2216.txt. Acesso em 3 jul. 2002.
[35] ZHANG, H. Service Disciplines for Guaranteed Performance Ser-vice in Packet-Switching Networks, Proceedings of the IEEE , v. 83, n. 10, out. 1995.
A
Expressões Analíticas para a Vazão de Fluxos TCP
A.1
Expressões obtidas em [22]
Em [22] a seguinte expressão é obtida para a vazão r de uma conexão TCP sujeita a perda de pacote com probabilidade p onde m é o tamanho máximo do segmento, T é o “round trip time"e c uma constante que depende do tipo de implementação do TCP.
r = mc
T √p (A.1)
A.2
Expressões obtidas em [23]
Os resultados em [23] se referem a duas situações extremas, correspondente a rede superdimensionada ou subdimensionada. Na situação de rede superdi-mensionada, não há perda de pacotes dentro do perfil - apenas aqueles fora do perfil são descartados com probabilidade p2. Na situação oposta, de
sub-dimensionamento, todos os pacotes fora do perfil são descartados enquanto os pacotes dentro do perfil são descartados com probabilidade p1. Os principais
resultados em [23] são sintetizados abaixo.
Supõe-se um Token-bucket de parâmetros (A,B) onde A é a taxa de tokens e B é a profundidade do token. A vazão obtida r é determinada para os dois casos extremos mencionados:
• Rede superdimensionada
r = 1 2(A + q (A2 + 6 p2T2) ; A ≤ 1 T[ q 2(B + 1 p2) + 2 √ 2B] 3A 4 + 3 2√2T( q B + 1 p2) ; caso contrário (A.2)
onde T é o valor de RTT e p2 a probabilidade de descarte de pacotes fora
do perfil.
Observa-se que se:
A ≤ 1 T[ r 2(B + 1 p2 ) + 2√2B] (A.3)
a vazão obtida não é influenciada pela profundidade do Token bucket.
• Rede subdimensionada r = min ( A,3 4 A + √ 2B T ! , 1 T r 3 2p1 ) (A.4)
Com base nesta expressão tem-se:
Se 1 T r 3 2p1 > A e B ≥ A2 T2 32 =⇒ r = A; (A.5) Se 1 T r 3 2p1 ≤ 3A 4 =⇒ r = 1 T r 3 2p1 ; (A.6) Se 3A 4 ≤ r 3 2p1 =⇒ r varia de 3A 4 à 1 T r 3 2p1 ; (A.7)
Os resultados acima se aplicam à situação de redução de janela por tri-plo ACK repetido. O time-out é também considerado pelos autores e leva à expressões bem mais complexas.
111
A.3
Expressões obtidas em [25]
Em [25] estende-se a modelagem desenvolvida em [22], que resulta em ex-pressões analíticas para a vazão efetiva dos fluxos AF utilizando o policiador TSW num ambiente de serviços diferenciados. A expressão em A.1 é modifi-cada para incluir o efeito de agregação e o relacionamento da probabilidade de perda de pacotes p com a probabilidade de pacotes fora do perfil e com a CIR ou taxa alvo. São descritos 3 cenários de para modelagem analítica que estão abaixo mencionadas. • Rede superdimensionada r = CIR 2 + s (CIR 2 ) 2 + (N√poF cM SS outRT T )2 (A.8) • Rede subdimensionada r = √pNocM SS inRT T (A.9) • Caso intermediário = (pout− pin)CIR 2pout + s ((pout− pin)CIR 2pout )2 + (N√oF cM SS poutRT T )2 (A.10)
onde MSS é o tamanho máximo do segmento, RTT é o round trip time, c uma constante que depende do tipo de implementação do TCP, NoF é
o número de fluxos AF , pin e pout são as probabilidades de descarte dos
pacotes dentro do perfil e fora do perfil respectivamente.
Simulações
B.1
O Simulador de Redes NS
O NS (Network Simulator-2 ) é um simulador baseado em eventos discre-tos e orientado a objediscre-tos para a simulação de redes. O objetivo do NS é proporcionar um ambiente para o desenvolvimento de pesquisas em torno dos protocolos que constituem a Internet, isto é, que utilizam a pilha TCP/IP, tanto no contexto das redes fixas quanto móveis, com fio e sem fio (redes lo-cais e de satélite). O NS foi desenvolvido (portado) para várias plataformas computacionais, sendo possível instalar o pacote em vários sabores Unix como, FreeBSD, Linux, SunOS e Solaris, além da plataforma Windows.
A biblioteca de protocolos e mecanismos implementados no NS é bastante vasta, abrangendo implementação dos protocolos TCP, UDP, IP além de disci-plinas de serviços, como, WFQ (Weight Fair Queueing), protocolos para redes móveis, como o IP móvel, tecnologias de redes sem fio locais e de longa distân-cia, como, 802.11, Bluetooth, GPRS (General Packet Radio Service) e DiffServ (Differentiated Services). Alguns destes não são distribuídos diretamente no pacote do NS, sendo contribuições disponibilizadas como patchs na página que hospeda as informações sobre o NS e que podem ser baixadas e adicionadas ao módulo básico através de recompilação do núcleo do simulador.
O NS fornece também bibliotecas de funções para a geração de alguns ti-pos de tráfego como: CBR (Constant Bit Rate) utilizado para simular tráfego constante e voz, ON-OFF para tráfego em rajada e voz comprimida, FTP para gerar tráfego correspondente a aplicações de transferência de arquivos e VBR (Variable Bit Rate) para tráfego com taxa de dados variável. Além das
113
bibliotecas com os módulos específicos de protocolos, tecnologias e geração de tráfego, o NS possui funções específicas de simulação e geração de números aleatórios. Ao invés de adotar uma única linguagem de programação, o pro-jeto do simulador levou em consideração o fato de que diferentes simulações requerem diferentes modelos de programação. Portanto, o NS adota duas lin-guagens de programação: C++ para o núcleo do simulador (back-end) e Otcl para construção de scripts e modelagem da simulação (fron-end). O objetivo é prover flexibilidade sem prejudicar o desempenho.
B.2
Topologia Utilizada
A topologia da Figura B.1 se apresenta com apenas 2 usuários corporativos cujos agregados são representados por S1, S2, ... , S6. Cada roteador de borda, com um enlace de saída de 2 Mbps, recebe o tráfego de sua rede e, antes de encaminhá-lo, deve analisar se o perfil do tráfego está conforme o contratado. Caso o tráfego esteja no perfil, ele será encaminhado com o respectivo code-point. Caso contrário, ações de degradação de codepoint ou de descarte de pacotes serão tomadas dependendo do contrato.
D1 D2 E2 E1 C1 E3 Enlace de Gargalo Roteador de Borda Roteador Central Cliente Domínio DiffServ S1 = EF S2 = AF S3 = BE S4 = EF S5 = AF S6 = BE 2 Mb 2 Mb
Figura B.1 Topologia Utilizada
B.3
Fontes de Tráfego
O tráfego em simulações não é gerado por aplicações reais na maioria das vezes (algumas vezes se usam traces). Quando se está projetando ou avali-ando algum protocolo ou mecanismo, deve-se utilizar modelos que simulem corretamente o tráfego gerado por aplicações, para que os resultados não se-jam invalidados por suposições incorretas. Em geral, a menos que se esteja modelando alguma aplicação, o importante em um modelo de tráfego são as características dos pacotes gerados: tamanho, protocolo de transporte, perio-dicidade, rajada etc.
As características das fontes de tráfego utilizadas nas simulações estão mos-tradas nas Tabelas 4.1 e 4.4 do capítulo 4.
B.4
Tamanho do Pacote
Um pacote IPv4 pode ter no máximo 64 Kbytes, mas na prática o tamanho máximo encontrado não vai além dos 1500 bytes. Isso se deve ao tamanho máximo do quadro Ethernet, que compõe a grande maioria das redes onde estão os servidores. Em geral, quanto maior o tamanho do pacote, melhor a utilização da rede, porque a quantidade de tráfego útil transmitido é maior, com o mesmo tamanho de cabeçalho. Para transmissão das fontes On/Off foram utilizados pacotes de 576 bytes e nas aplicações FTP o tamanho de segmento TCP foi de 1 Kbytes.
B.5
Tempo de Simulação
Uma regra empírica para escolher o tempo de simulação é iniciar com um valor baixo e ir dobrando o tempo para verificar a alteração dos resultados. No momento em que as alterações forem muito baixas (algo subjetivo), pode-se ficar com o valor anterior. Para tempo de simulação, dependendo da
115
dade de eventos da simulação, algo entre alguns minutos a algumas horas é um valor razoável. O tempo de relógio é geralmente menor que o tempo de simula-ção, mas ele é influenciado pelo número de repetições, necessário para garantir confiabilidade estatística aos resultados. Nas simulações realizadas neste tra-balho, a metodologia utilizada foi determinar empiricamente o tempo mínimo de simulação para o qual os valores dos parâmetros observados se estabilizaram (convergência), mostrando uma diferença da ordem de 1% em relação a uma simulação com o dobro de tempo. Um tempo de 1000 s se mostrou suficiente para esta convergência em todas as simulações.
B.6
Códigos Fontes
Os códigos fontes referentes a todas as simulações realizadas mais o arquivo texto desta dissertação se encontram disponibilizadas no endereço eletrônico http : //mamona.cetuc.puc − rio.br/ ∼ carlos, na seção Academic Informa-tion.
