4
TCP em Ambiente de Serviços Diferenciados
Neste capítulo fazemos um estudo sobre desempenho de redes DiffServ,
focalizando o comportamento de fluxos TCP. Como descrito no Capítulo 2, o
TCP apresenta mecanismos próprios de controle de fluxo e congestionamento.
Estes interagem com os mecanismos de controle de tráfego das redes DiffServ
PUC-Rio - Certificação Digital Nº 0016489/CA
como resumido a seguir.
As estratégias de implementação de QoS geralmente estabelecem uma taxa
de dados máxima com a qual um fluxo ou um conjunto de fluxos podem transmitir. Caso os fluxos extrapolem essa taxa de pico, várias ações podem ser
tomadas. Uma delas é descartar pacotes, o que leva fluxos TCP a diminuírem
sua janela de transmissão. Conseqüentemente, por um determinado período de
tempo, a taxa máxima permitida não é alcançada, o que significa desperdício
de recursos contratados. Ou seja, o mecanismo de controle de congestionamento do TCP exerce grande influência na obtenção dos requisitos mínimos
de QoS estabelecidos, sobretudo com relação à largura de banda.
O entendimento da dinâmica dos mecanismos de controle de tráfego do
TCP em cenários típicos de uma rede DiffServ é importante para o dimensionamento da rede. Assim, inicialmente fazemos um apanhado de resultados
analíticos e de simulações sobre o assunto e procuramos, com base nestes resultados, obter critérios de escolha de parâmetros em um estudo específico de
caso.
Modelagem Analítica
75
4.1
Modelagem Analítica
Nos últimos anos tem-se observado bastante interesse de pesquisadores na
modelagem analítica do protocolo TCP, considerando seus mecanismos de controle de tráfego e congestionamento. Em geral, o objetivo destes estudos é
determinar expressões analíticas para a vazão obtida em uma conexão TCP
em função de parâmetros como probabilidade de perda de pacotes, Round Trip
Time e banda de enlace, levando em conta o efeito de mecanismos utilizados
no controle de tráfego. Isto é feito em [22], cujo principal resultado se resume
na expressão apresentada no Apêndice A.1.
Mais recentemente, a modelagem analítica de fluxos TCP tem sido con-
PUC-Rio - Certificação Digital Nº 0016489/CA
siderada no contexto de redes DiffServ. Em [20] procura-se determinar, de
forma simplificada, o efeito da estratégia de diferenciação baseada na marcação de pacotes IN e OUT, e descarte diferenciado destes pacotes em caso de
congestionamento. Considera-se um tamanho máximo de janela Wmax e um
tamanho Wa correspondente à taxa alvo. Enquanto a janela estiver abaixo
de Wa , todos os pacotes são marcados como dentro do perfil (IN ); quando a
janela ultrapassa Wa , os pacotes são marcados como OUT. Usando modelagem desenvolvida em [24] mostra-se o relacionamento entre a vazão obtida, os
tamanhos de janela Wa e W, e as probabilidades de perda de pacotes IN e
OUT. Os resultados mostram o aumento da vazão à medida em que aumenta
a janela Wa dentro da qual os pacotes são preferenciais(IN ).
Um estudo bem mais abrangente é apresentado em [23], onde a marcação
dos pacotes IN e OUT é feita através de um token bucket e o gerenciamento
ativo de buffer através do mecanismo multi-RED. A partir de um conjunto
de resultados analíticos, são obtidos alguns critérios que, segundo os autores,
podem ser úteis para (i) um usuário especificar um perfil adequado de tráfego
para obter uma determinada vazão; (ii) um provedor de serviços alocar recursos
entre diferentes usuários para atender as vazões desejadas quando for possível
e negá-los quando não for. Especificamente, são obtidas relações entre os
parâmetros do token bucket e a vazão efetiva. Os autores observam em seus
Estudos Através de Simulações
76
estudos basicamente três resultados: (i) a taxa alcançada não é proporcional
à taxa alvo; (ii) não é sempre possível alcançar a taxa alvo e (iii) existe uma
faixa de valores em que os parâmetros do token bucket não exercem influência
sobre a taxa alcançada. As expressões analíticas das vazões são apresentadas
no Apêndice A.2.
Análise semelhante é apresentada em [25] considerando policiador TSW em
vez de Token Bucket. Em [25] estende-se a modelagem desenvolvida em [22],
que resulta em expressões analíticas para a vazão efetiva em ambiente de serviços diferenciados. Tem-se assim, uma outra forma de prever analiticamente
a banda obtida em agregado AF-TCP. Estas expressões analíticas são apresentadas no Apêndice A.3.
PUC-Rio - Certificação Digital Nº 0016489/CA
4.2
Estudos Através de Simulações
Diversos resultados de simulações envolvendo o desempenho de transmissão
através do protocolo TCP em ambiente de serviços diferenciados têm sido
publicados nos anos recentes. Alguns destes trabalhos [26, 27] são revistos
aqui.
Em [27] é examinada a influência de vários parâmetros na obtenção das
taxas requeridas. A topologia, apresentada na Figura 4.1, foi selecionada para
refletir uma rede DiffServ com um gargalo de 5 Mbps no roteador central
simulando um congestionamento. São definidos fluxos agregados entre dois
pares de clientes (T1 e T2), tendo cada agregado uma parte como serviço
assegurado e outra com serviço BE. Os dois agregados atravessam os roteadores
de borda (E1 e E2), os quais promovem policiamento, marcação e classificação
baseados em endereço IP fonte/destino. Estes agregados convergem para um
roteador de núcleo (C1) e compartilham um enlace gargalo, e são encaminhados
aos respectivos clientes pares (D1 e D2) através do roteador de borda (E3).
Utiliza-se policiamento/marcação com TSW e o sistema de gerenciamento de
filas é o RIO, onde o serviço BE é tratado como fora de perfil (out).
As questões investigadas em [27] e as respectivas conclusões são resumidas
a seguir:
Estudos Através de Simulações
77
T1
D1
E1
5 Mbps
C1
T2
E2
Roteador de Borda
E3
D2
Cliente
Roteador Central
Figura 4.1 Topologia de Simulação
• RTT: quanto maior o valor de RTT, menor é a captura do excesso de
banda quando não há congestionamento e menor é a banda conseguida
em situação de congestionamento.
• Número de microfluxos: quanto maior o número de microfluxos, mais
banda é alcançada por estes microfluxos. Os autores sugerem mais estu-
PUC-Rio - Certificação Digital Nº 0016489/CA
dos.
• Valor da banda alvo: o valor da taxa requerida não tem impacto muito
grande no serviço contrato; não está estabelecido um influência clara.
• Tamanho do pacote: variou-se o pacote de 256-1500 bytes e notou-se que
quanto maior o tamanho do pacote mais banda é alcançada pelo agre-
gado. 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.
• Interação com fluxo UDP: mostra-se que o serviço BE sobre UDP pode
ficar sem banda (starvation); mostra-se também a vantagem de fluxos
UDP sobre fluxos TCP na obtenção de banda em excesso, pelo fato
de não apresentarem controle de congestionamento, configurando o chamado tráfego “irresponsável”.
Em [26] apresenta-se um estudo semelhante em outra topologia. Considerouse um agregado com dez fluxos TCP entrando na rede através de um roteador
de borda e compartilhando um enlace de gargalo com fluxos BE provenientes
de outros roteadores. Neste caso, trabalha-se com policiador Token Bucket em
vez do TSW, pacotes de 1000 bytes e gerenciamento de filas RIO cujos parâmetros são arbitrados. Investiga-se, basicamente, a capacidade de obtenção
Estudo de Caso
78
da banda contratada. Mostra-se que os fluxos com menor banda contratada
são favorecidos. Como referência para obtenção de banda com eqüidade, é
usada uma distribuição teórica ideal do excesso da banda. Examina-se também o impacto do RTT, mostrando-se que as conexões com menor RTT são
favorecidas.
O comportamento do Token Bucket é outro item analisado em [26], observandose uma pequena variação na taxa obtida para valores típicos da profundidade
do Token Bucket (5 a 15 pacotes).
4.3
Estudo de Caso
PUC-Rio - Certificação Digital Nº 0016489/CA
Os estudos sobre o comportamento de fluxos TCP em redes DiffServ, alguns dos quais resumidos anteriormente, têm identificado as questões mais
relevantes e fornecido subsídios para dimensionamento da rede. Nosso objetivo aqui é usar as informações recolhidas nestes trabalhos e a capacidade de
realizar novas simulações (que mostraremos a seguir), no sentido de ampliar
estes subsídios.
Partindo destas considerações, definimos um modelo com as seguintes características básicas:
• um conjunto de usuários corporativos de um mesmo provedor de serviços
diferenciados;
• cada usuário corporativo tem um mesmo conjunto de fontes de tráfego
com diferentes requisitos de QoS que deverão ser especificados através
dos PHB’s AF e EF, ou se enquadrarem na categoria de melhor-esforço;
• cada usuário corporativo se liga ao provedor através de um enlace de
acesso de 2 Mbps;
Apresentamos um modelo simplificado de um provedor de Internet, que
implementa serviços diferenciados, oferecendo assinaturas ouro, prata e bronze,
associadas a PHB’s EF, AF e BE de acordo com políticas definidas na forma
de contratos de serviço. Os serviços oferecidos pelo provedor são descritos a
seguir:
Estudo de Caso
79
• Assinatura Ouro: Desempenho melhor dentre todos os outros. Ideal
para aplicações com estritos requisitos de tempo, como vídeo conferência
por exemplo, pois fornece garantias rígidas de baixo atraso, baixa perda,
baixo jitter, bem como largura de banda assegurada. Na rede, o tráfego
ouro tem prioridade sobre os demais. Esse serviço é implementado utilizando o PHB EF e o condicionamento de tráfego é realizado através do
descarte de pacotes fora do perfil contratado. Taxa alvo: 500 Kbps.
• Assinatura Prata: Ideal para clientes que desejam um serviço melhor que o bronze, mas que não desejam pagar pela assinatura Ouro. É
adequado para WWW, Telnet, FTP etc. Esse serviço é implementado
utilizando o PHB AF e o condicionamento de tráfego é realizado através
da remarcação de pacotes fora do perfil contratado. Taxa alvo: 1000
PUC-Rio - Certificação Digital Nº 0016489/CA
Kbps.
• Assinatura Bronze: Caracteriza-se pelo desempenho regular que atende
às necessidades de usuários que utilizam aplicações Internet, tais como
e-mail, FTP. O tempo de acesso é variável, ou seja, em certos momentos
a rede pode estar lenta, porém ela pode se apresentar mais rápida em
outros instantes. Esse serviço equivale ao melhor-esforço, oferecido hoje
pela Internet.
Estudo de Caso
80
4.3.1
Modelo Utilizado
Apresentamos a seguir a topologia da rede e os parâmetros usados nas
simulações. Este modelo é basicamente o mesmo utilizado em [30] onde se
procurou avaliar a eficiência de mecanismos de controle de tráfego. No apêndice
B estão resumidos os parâmetros de simulação utilizados.
A topologia considerada está mostrada na Figura 4.2, onde C1 representa
um provedor de acesso à Internet que implementa serviços diferenciados, sendo
sua função principal encaminhar fluxos agregados aos destinos D1 e D2. Os
roteadores de borda E1 e E2 representam os roteadores dos usuários responsáveis por policiamento, marcação e descarte de pacotes. O roteador C1 faz o
PUC-Rio - Certificação Digital Nº 0016489/CA
encaminhamento de acordo com a classe do agregado. Os enlaces de acesso ao
provedor possuem banda de 2 Mbps e latência de 5 ms.
A topologia da Figura 4.2 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 codepoint. Caso contrário, ações de degradação de codepoint ou de descarte de
pacotes serão tomadas dependendo do contrato.
Uma vez passado pelos roteadores de extremidade, o tráfego é encaminhado
para o roteador central que o tratará de acordo com o codepoint marcado.
Passado o roteador central, os pacotes são encaminhados para o roteador E3
para, em seguida, serem enviados para os respectivos destinos. Considera-se
que a latência de cada enlace é de 5 ms.
A Figura 4.3 ilustra o processamento de tráfego nos roteadores E1 e E2.
Nestes roteadores de borda, os agregados de tráfego EF e AF, como possuem
um perfil de contrato, são encaminhados para os respectivos policiadores. Já
no tráfego BE não ocorrem ações de policiamento pois ele não é objeto de
contrato de serviço.
Após as ações ocorridas no bloco de policiamento, medição, suavização,
descarte e remarcação dos pacotes, os tráfegos EF e AF são encaminhados
Estudo de Caso
81
S1 = EF
Domínio DiffServ
S2 = AF
S3 = BE
E1
S4 = EF
E2
D1
Enlace de
Gargalo
2 Mb
C1
E3
2 Mb
S5 = AF
D2
S6 = BE
Cliente
Roteador de Borda
Roteador Central
Figura 4.2 Modelo Utilizado
Fluxos On/Off
Fluxos EF/UDP
Classificador MF
Marcador/Policiador
Fluxos FTP
Fluxos AF/TCP
Classificador MF
Fluxos FTP
Fila Drop Tail
Fila RIO
Marcador/Policiador
Fluxos BE/TCP
Fila RED
PUC-Rio - Certificação Digital Nº 0016489/CA
Classificador MF
E
S
C
A
L
O
N
A
D
O
R
Acesso 2 Mbps
Figura 4.3 Processamento nos roteadores de borda E1 e E2
para as respectivas filas de saída. Nessas filas de saída, os pacotes são servidos
através de uma disciplina de escalonamento e o seu descarte ocorrerá de acordo
com o gerenciamento ativo de filas implementado.
Após passarem pelo roteador de borda, os pacotes são encaminhados para
o roteador central. Nele são classificados de acordo com o seu DSCP e encaminhados para as respectivas filas de saída, onde novamente são servidos e descartados de acordo com a disciplina de escalonamento e o gerenciamento ativo
de filas escolhido. O processamento no roteador de núcleo está mostrado na
Figura 4.4
As características das fontes de tráfego estão mostradas na Tabela 4.1.
Como se observa, definimos para cada usuário corporativo, na classe EF, 24
fontes On/Off cada uma com taxa de 64 Kbps no período ativo. Considerando
a duração média do período ativo igual a 0.5 s e a duração média do período de
silêncio igual a 1.0 s tem-se uma taxa média de 21.33 Kbps por fonte. Apesar
de que a recomendação P.59 do ITU-T sugere duração média do período ativo
igual a 1.004 s e a duração média do período de silêncio igual a 1.587 s, os
Estudo de Caso
82
Fluxos EF/UDP
Fluxos Agregados
Fila Drop Tail
Fluxos AF/TCP
Fila RIO
Fluxos BE/TCP
Fila RED
Classificador BA
E
S
C
A
L
O
N
A
D
O
R
Tronco
Figura 4.4 Processamento no roteador de núcleo C1
períodos fixados de 0.5 s e 1.0 s para simulação estão dentro de uma faixa de
valores típicos e podem ser considerados representativos de algum tipo de voz.
Na classe AF são definidas 8 fontes com tráfego correspondente a aplicações
FTP, cada uma com taxa alvo contratada de 128 Kbps, e na classe BE 8 fontes
PUC-Rio - Certificação Digital Nº 0016489/CA
(sem taxa contratada) correspondente a aplicações FTP. Isto corresponde aos
seguintes percentuais aproximados para cada classe de serviço, de acordo com
o PHB: 25% para o PHB EF, 50% para o PHB AF e 25% para o tráfego de
melhor-esforço. 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.
Fonte
PHB Tipo de Tráfego
Característica do Tráfego
TaxaON = 64 Kbits/s
S1, S4
EF
Fontes ON-OFF
TaxaMédia = 21.33 Kbits/s
No de Fontes = 24
Pacote = 1000 bytes
S2, S5
AF
FTP
TaxaAlvo = 128 Kbits/s
No de Fontes = 8
S3, S6
BE
FTP
Pacote = 1000 bytes
No de Fontes = 8
Tabela 4.1 Características das Fontes de Tráfego
As configurações dos policiadores de tráfego e dos parâmetros do gerenciamento ativo estão especificadas nas Tabelas 4.2 e 4.3. Como se observa, os
Estudo de Caso
83
valores do parâmetro CIR são iguais às taxas contratadas para as classes EF e
AF. Quanto ao valor de CBS, o valor para a classe AF foi estabelecido a partir
de estudo realizado em [30]. Os parâmetros RIO: Pmax , M inth e M axth são
explicados no Capítulo 2 e definidos de acordo com valores típicos usados em
simulações, algumas descritas na seção 4.2.
Tráfego
Policiador
CBS
Tráfego
Mbits/s
bytes
Excedente
S1-D1
Token Bucket
0.512
8000
Descarta
S2-D1
Token Bucket
1.024
4000
Degrada DSCP
S3-D1
PUC-Rio - Certificação Digital Nº 0016489/CA
CIR
Tráfego BE - Sem Policiamento
S4-D2
Token Bucket
0.512
8000
Descarta
S5-D2
Token Bucket
1.024
4000
Degrada DSCP
S6-D2
Tráfego BE - Sem Policiamento
Tabela 4.2 Características dos Policiadores
Tráfego
Tipo de Gerenciamento
Pmax
Minth
Maxth
EF
DropTail
1
2
2
AF - No Perfil
RIO
0.02
20
40
AF - Fora do Perfil
RIO
0.1
10
20
BE
RED
0.1
10
20
Tabela 4.3 Características do Gerenciamento Ativo de Filas
O escalonamento utilizado, tanto no roteador de borda como no roteador de núcleo, será um escalonamento híbrido (hierárquico) descrito na seção
3.3.1 com as seguintes características: prioridade da fila EF sobre as outras;
escalonamento WRR entre as filas AF e BE com tempos de serviço com pesos
proporcionais às taxas contratadas, ou seja, aproximadamente 2 para 1 (2 bits
atendidos contra 1 bit) respectivamente.
Estudo de Caso
84
4.3.2
Simulações
Serão descritas a seguir um conjunto de simulações realizadas com o objetivo de avaliar o comportamento do tráfego TCP sob vários aspectos, alguns
já analisados na Literatura em diferentes cenários e outros ainda não devidamente avaliados. Entre estes últimos incluímos a comparação de desempenho
considerando os 2 principais tipos de policiadores: Token Bucket e TSW no
roteador de borda, diferentes implementações do TCP, estratégias de encaminhamento e classificação. Na realidade o modelo simulado inclui tráfego
UDP na classe EF. Assim, resultados de vazão para este tipo de tráfego são
ocasionalmente apresentados como referência para comparação.
PUC-Rio - Certificação Digital Nº 0016489/CA
Todas as simulações foram realizadas com o Network Simulator-versão
2 [28]. Para simulação dos mecanismos de uma rede DiffServ foi usado um
pacote desenvolvido pela Nortel Networks [29]. Este pacote inclui mecanismos
de condicionamento, suavização e descarte, e outros que permitem a implementação de serviços baseados nos PHBs EF e AF, além do serviço BE. Foi
acrescentado ao pacote Nortel [29] a implementação do escalonamento usado.
Como relatado no Capítulo 4 de [30], a consistência e precisão do software foi testada com base em resultados analíticos conhecidos. Os resultados apresentados tiveram como objetivo analisar a fidelidade dos resultados
estatísticos, obtidos no NS-2, com as expressões analíticas apresentadas anteriormente implementadas no Mathlab. O modelo analítico correspondente ao
esquema Threshold Dropping (TD), mostrado anteriormente na seção 3.3.3, foi
implementado no simulador NS. A análise, feita na simulação, prendeu-se aos
resultados de atraso médio e da probabilidade de perda de pacotes do tráfego
de alta prioridade. Nela, visou-se analisar a robustez dos resultados através
da variação dos parâmetros: taxa do tráfego de alta prioridade (λh ), taxa do
tráfego de baixa prioridade (λl ) e tamanho do buffer BlT D . Os resultados de
probabilidade de perda de pacotes mostraram um bom grau de fidelidade ao
modelo analítico, com resultados muito próximos para erros da ordem de 10−7 .
Similarmente a análise de probabilidade de perda de pacote, fez-se uma análise do atraso médio sofrido pelo tráfego de alta prioridade. Com base nos
Estudo de Caso
85
resultados obtidos, percebeu-se que o simulador NS-2 possui um bom nível de
confiabilidade, pois os resultados estatísticos relativos ao sistema TD chegaram
bem próximo do comportamento de suas funções analíticas. Nas simulações realizadas neste trabalho, 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.
4.3.2.1
Efeito de Parâmetros na Vazão dos Fluxos TCP
Tronco
Começaremos analisando o comportamento da vazão dos fluxos agregados,
variando a taxa do enlace tronco (entre C1 e E3 da Figura 4.2) de 3 a 4 Mbps.
Esta análise permite avaliar a necessidade de banda do provedor para atender
os contratos de serviço. Os resultados estão mostrados na Figura 4.5.
1200000
1000000
Vazão (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
A)Vazão Efetiva dos Fluxos Agregados em Função da Banda do Enlace
EF1
800000
AF1
BE1
600000
EF2
AF2
400000
BE2
200000
0
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
4.0
Capacidade do Enlace (Mbits)
Figura 4.5 Vazão Efetiva dos Fluxos Agregados
Podemos observar que os tráfegos de mesma classe recebem a mesma banda.
O tráfego EF obtém sempre a banda contratada e que os tráfegos AF e BE
aumentam sua vazão à medida que aumenta a banda do enlace tronco, só
Estudo de Caso
86
conseguindo a taxa contratada quando a banda do enlace tronco atinge 3.9
Mbps.
B)Impacto do Round Trip Time
A seguir analisamos o impacto do RTT na vazão dos fluxos AF. Estabelecemos o valor de 5 ms de latência para cada enlace, e assim o RTT correspondente
à topologia da Figura 4.2 equivale a 40 ms. Aumentando progressivamente a
latência do enlace de acesso do usuário 2, variamos o RTT dos agregados AF2
e BE2 de 60ms a 160ms. Consideramos o enlace tronco superdimensionado.
O resultado está mostrado na Figura 4.6 onde se observa a degradação do
fluxo AF2 à medida que aumenta o valor de seu RTT. Este resultado pode
ser explicado pelo mecanismo da janela de transmissão do TCP. De acordo
com este mecanismo, o transmissor só pode enviar mais segmentos ao receber
dendo do RTT. Assim o protocolo TCP ajusta automaticamente sua taxa de
transmissão ao enlace mais lento da rede.
1070000
1065000
Vazão (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
um novo ACK, o que acontece mais rapidamente ou mais lentamente depen-
1060000
AF1
AF2
1055000
1050000
1045000
1040000
60
80
100
120
140
160
RTT (ms)
Figura 4.6 Impacto do RTT nos fluxos AF
Portanto, fluxos agregados com diferentes valores de RTT, apesar de terem
a mesma taxa alvo, obterão diferentes taxas, sendo penalizados os fluxos com
maiores valores de RTT. Os resultados aqui apresentados estão de acordo com
[27]. Deve-se notar porém que, apesar das pequenas diferenças nas vazões, os
2 fluxos obtêm as taxas contratadas.
A Figura 4.7 mostra o comportamento da vazão dos fluxos BE. Como o
enlace de acesso é de 2 Mbps, notamos claramente que a banda excedente é
Estudo de Caso
87
absorvida pelo fluxo BE2 em virtude do fluxo AF2 se degradar por causa do
Vazão (Kbps)
aumento do RTT.
460000
455000
450000
445000
440000
435000
430000
425000
420000
415000
410000
BE1
BE2
60
80
100
120
140
160
RTT (ms)
C)Comparação entre Token Bucket e TSW
A simulação do item A foi repetida considerando-se tipos diferentes de
policiadores/ marcadores para os usuários 1 e 2. Para o usuário 1 (roteador
E1) manteve-se o mesmo Token Bucket do item A e para o usuário 2 (roteador
E2) utilizou-se o policiador TSW. O marcador TSW descrito em [25] e na seção
3.2.3.3 estima a taxa de transmissão em um determinado intervalo de tempo e
a marcação é feita com base nesta taxa estimada. O resultado está mostrado
na Figura 4.8.
1200000
1000000
Vazão (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
Figura 4.7 Impacto do RTT nos fluxos BE
EF1
800000
AF1
BE1
600000
EF2
AF2
400000
BE2
200000
0
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
4.0
Capacidade do Enlace (Mbits)
Figura 4.8 Vazões dos Agregados com Diferentes Policiadores
Estudo de Caso
88
Observando a Figura 4.8, percebemos que o fluxo AF2-TCP utilizando o
policiador TSW obteve melhor desempenho que o fluxo AF1-TCP utilizando
o policiador Token Bucket, sendo que a diferença de desempenho aumenta a
medida que diminui a banda disponível e tende a desaparecer quando o enlace
é superdimensionado. Este resultado indica a vantagem do TSW sobre o Token
Bucket. Porém mais estudos seriam necessários para uma conclusão deste tipo.
Repetimos a simulação anterior incrementando o tamanho do balde CBS,
inicialmente em 4 Kbytes conforme Tabela 4.2, e deixando o enlace tronco em
situação de congestionamento (3 Mbps). O resultado é mostrado na Figura
4.9.
840000
820000
800000
Vazão (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
780000
760000
740000
AF1
720000
AF2
700000
680000
660000
640000
620000
600000
4
5
6
7
8
9
10
11
12
13
14
CBS (Kbytes)
Figura 4.9 Influência do CBS nas Vazões dos Agregados
Percebemos que a vazão do agregado AF2-TCP utilizando o policiador
TSW degrada seu desempenho quando aumentamos o balde CBS do token
bucket numa faixa de 5 a 13 Kbytes em situação de congestionamento, se igualando a partir de um CBS de 14 Kbytes. Em contrapartida a vazão do agregado
AF1-TCP melhora seu desempenho como era de se esperar, pois compartilham
o mesmo enlace de acesso de 2 Mbps. Observamos que devemos dimensionar
corretamente o CBS do token bucket quando existir outros usuários utilizando
outros tipos de policiadores.
Estudo de Caso
89
4.3.2.2
Desempenho do TCP - Diferentes Implementações e Estratégias de
Encaminhamento e Classificação
A)Vazão dos Agregados AF e BE com diferentes Implementações
Analisamos agora o comportamento dos fluxos TCP em suas diversas implementações. Como comentadas no capítulo 2, existem diversas implementações
do TCP, cada uma delas com algoritmos diferentes de controle de congestionamento. Por isso, dois usuários com a mesma probabilidade de descarte de
pacotes, porém com implementações diferentes podem obter diferentes vazões.
Para analisar este efeito, simulamos os agregados AF1 e BE1 com uma
TCP em situação de congestionamento (enlace tronco de 3 Mbps). A simulação
foi realizada utilizando os mesmos parâmetros configurados nas Tabelas 4.1,
4.2 e 4.3. Fizemos a análise temporal das vazões dos agregados para avaliarmos
o desempenho de cada implementação TCP. A seguir discutimos os resultados
obtidos.
i)RENO versus SACK Percebemos na Figura 4.10 que a vazão do agreVazões AF e BE - Variações TCP
1000
Vazão (Kbps)
PUC-Rio - Certificação Digital Nº 0016489/CA
implementação de TCP e os agregados AF2 e BE2 com outra implementação de
AF1-Reno
AF2 - Sack
BE1- Reno
BE2-Sack
800
600
400
200
0
100 200
300 400 500
600 700 800
900 1000
Tempo (seg)
Figura 4.10 Vazões AF e BE: Reno versus Sack
gado TCP-AF2-SACK é superior em relação ao agregado TCP-AF1RENO. A vazão média do agregado TCP-AF2-SACK é de 808 Kbps
Estudo de Caso
90
enquanto que a vazão média do agregado TCP-AF1-RENO é 674 Kbps.
A vazão média do agregado TCP-BE2-SACK é de 266 Kbps enquanto
que a vazão média do agregado TCP-BE1-RENO é 238 Kbps. Apesar
de terem os mesmos algoritmos de controle de congestionamento e de
o TCP RENO ser o mais difundido atualmente pela Internet, o TCP
SACK se diferencia na política de retransmissões decorrente da opção de
reconhecimentos seletivos.
ii) TAHOE versus SACK
Como mostrado na Figura 4.11 acima o fluxo TCP-AF2-SACK conse-
agregado TCP-AF2-SACK é de 788 Kbps enquanto que a vazão média
do agregado TCP-AF1-TAHOE é 695 Kbps. A vazão média do agregado
TCP-BE2-SACK é de 255 Kbps enquanto que a vazão média do agregado
TCP-BE1-TAHOE é 253 Kbps. Mostrando assim, mais uma vez que, o
controle de congestionamento do protocolo TCP atua de forma diferente
em cada implementação, alterando suas vazões médias.
Vazões AF e BE - Variações TCP
Vazão (Kbps)
PUC-Rio - Certificação Digital Nº 0016489/CA
guiu se sobressair ao agregado TCP-AF2-TAHOE. A vazão média do
1000
900
800
700
600
500
400
300
200
100
0
AF1 Tahoe
AF2 Sack
BE1 Tahoe
BE2 Sack
100 200 300 400 500 600 700 800 900 1000
Tempo (seg)
Figura 4.11 Vazões AF e BE: Tahoe versus Sack
Estudo de Caso
91
iii) VEGAS versus SACK
O resultado da Figura 4.12 mostra o fluxo TCP-AF2-SACK como uma
vazão muito superior ao fluxo TCP-AF1-VEGAS. A vazão média do
agregado TCP-AF2-SACK é de 910 Kbps enquanto que a vazão média
do agregado TCP-AF1-Vegas é 571 Kbps. A vazão média do agregado
TCP-BE2-SACK é de 266 Kbps enquanto que a vazão média do agregado
TCP-BE1-TAHOE é 238 Kbps. Sem dúvida, o fluxo TCP-AF1-VEGAS
foi o que apresentou pior resultado dentre todas as outras implementações, pois no TCP Vegas não se aplica os algoritmos fast recovery e fast
retransmit.
Vazões AF e BE - Variações TCP
1000
Vazão (Kbps)
PUC-Rio - Certificação Digital Nº 0016489/CA
1200
AF1 Vegas
AF2 Sack
BE1 Vegas
BE2 Sack
800
600
400
200
0
100 200 300 400 500 600 700 800 900 1000
Tempo (seg)
Figura 4.12 Vazões AF e BE: Vegas versus Sack
iv) TCP NewReno
Foram realizadas também simulações com a implementação TCP NewReno. Os resultados foram similares aos obtidos com a implementação
TCP Reno.
Estudo de Caso
92
B)Estratégia de Encaminhamento
A seguir, ao mesmo tempo que comparamos implementações do TCP para
diferentes valores de banda do enlace tronco, analisamos também a questão do
encaminhamento ou não dos pacotes fora do perfil para o roteador central. Tal
estratégia de encaminhamento foi objeto de modelagem analítica [20]. Para
analisar este problema, simulamos agregados AF1 e BE1 com implementação
TCP Reno , fluxos AF2 e BE2 com implementação TCP Sack. Escolhemos as
implementações TCP Reno e Sack pois foram as implementações que apresentaram melhor desempenho em situação de congestionamento nas simulações
anteriores. As simulações foram realizadas utilizando os mesmos parâmetros
configurados nas Tabelas 4.1, 4.2 e 4.3.
Foi determinada a vazão dos agregados AF variando o enlace tronco de
descarte dos pacotes fora do perfil e na Figura 4.14 os resultados obtidos com
a estratégia de encaminhar pacotes fora do perfil.
Vazão Efetiva (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
3 a 4 Mbit/s. Na Figura 4.13 são apresentados os resultados da vazão com
1050000
1020000
990000
960000
930000
900000
870000
840000
810000
780000
750000
720000
690000
660000
630000
600000
AF1
AF2
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
4.0
Capacidade do Enlace (Mbits)
Figura 4.13 Vazões AF descartando pacotes out
Os resultados confirmaram a vantagem do TCP Sack sobre o Reno nas
duas estratégias, vantagem que se acentua para valores menores de banda do
enlace tronco. Quanto às estratégias de encaminhamento verifica-se que o
encaminhamento de pacotes fora do perfil permite obter ligeiro aumento de
vazão para todos os valores de banda do enlace tronco, permitindo inclusive
ultrapassar os valores contratados quando a banda atinge 4 Mbps.
Estudo de Caso
93
1100000
Vazão Efetiva (bits/s)
1050000
1000000
950000
900000
AF1
AF2
850000
800000
750000
700000
650000
600000
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
4.0
Capacidade do Enlace (Mbits)
Figura 4.14 Vazões AF encaminhando pacotes out
PUC-Rio - Certificação Digital Nº 0016489/CA
C)Estratégias de Classificação
Nos casos analisados, anteriormente, foram consideradas as 3 classes básicas
de tráfego em ambiente de serviços diferenciados, ou PHB’s: EF, AF, e BE.
Cada uma destas classes foi representada por um determinado número de fontes
de tráfego. No caso da classe EF, foram simuladas fontes On-Off, e para as
classes AF e BE fontes FTP/TCP.
Como visto no capítulo 3, existe a opção de se estabelecer classes distintas
dentro do PHB AF e, dentro de cada classe, diferentes níveis de precedência
para descarte de pacote. Com isso, um determinado tipo de tráfego pode
receber uma designação AFij , onde i representa a classe e j a precedência de
descarte.
Na presente análise será considerada a mistura de tráfegos com perfis iguais
dentro do mesmo PHB AF, especificamente, FTP. Além disto, serão examinadas duas alternativas de classificação, ilustradas nas Figuras 4.15 e 4.16, com
usuários com diferentes implementações TCP. De acordo com a Figura 4.15,
os dois tipos de tráfego AF serão encaminhados através de um mesmo buffer e diferenciados pela probabilidade de descarte (mesma classe - diferentes
precedências). De acordo com a Figura 4.16, a diferenciação será feita pelo
encaminhamento através de buffers separados (classes diferentes). Em ambos
cenários de simulação, os usuários utilizam implementações TCP diferentes (o
usuário que utiliza o roteador E1 usa TCP Reno e o outro usuário utiliza TCP
Estudo de Caso
94
Sack).
Drop-Tail
AF1.1
Policiador
Classificador
Servidor
Servidor
RIO
RIO
AF1.2
Drop-Tail
Escalonador
Policiador
Escalonador
EF
Policiador
Roteador de Borda
Roteador Central
Figura 4.15 Classificação de tráfego AF por diferentes níveis de descarte
EF
Policiador
PUC-Rio - Certificação Digital Nº 0016489/CA
AF2
Policiador
RIO
Policiador
Drop-Tail
Servidor
RIO
Roteador de Borda
Classificador
RIO
Escalonador
AF1
Escalonador
Drop-Tail
Servidor
RIO
Roteador Central
Figura 4.16 Classificação de tráfego AF pela utilização de buffers diferentes
Considera-se, inicialmente, que as fontes de tráfego possuem as características apresentadas na Tabela 4.4, onde se observa a definição de duas classes
dentro do PHB AF, ambas constituídas por tráfego FTP. Os parâmetros de
policiamento de tráfego são os apresentados na Tabela 4.5 e o gerenciamento
ativo de filas tem os parâmetros apresentados na Tabela 4.6. Com relação
aos policiadores observa-se que os token buckets apresentam os mesmos valores para o parâmetro CBS. No que se refere ao gerenciamento ativo de filas
nota-se que os fluxos AF usam filas RIO.
O objetivo desta análise será estabelecer relacionamento entre a capacidade
de diferenciação de fluxos através dos parâmetros dos mecanismos de controle
de tráfego. Para estratégia de buffers separados, uma maior ou menor diferenciação é conseguida ajustando-se os pesos do escalonador WRR. No esquema
de buffer único, essa diferenciação é alcançada através dos parâmetros do gerenciador ativo, isto é, Pmax , M inth e M axth . A análise é feita com a banda
do enlace tronco em 3.5 Mbps, representando uma condição de subdimensionamento.
Estudo de Caso
Fonte
95
Classe DiffServ
1.
4.
3.
2.
Tipo de Tráfego
Característica do Tráfego
TaxaON = 64 kbps
S1, S4
EF
Exponencial ON-OFF
TaxaMédia = 21.33 Kbps
No de Fontes = 24
S2, S5
AF1
FTP
S3, S6
AF2
FTP
TaxaAlvo = 128 Kbps
No de Fontes = 8
TaxaAlvo = 58 Kbps
No de Fontes = 8
PUC-Rio - Certificação Digital Nº 0016489/CA
Tabela 4.4 Características das Fontes de Tráfego
Tráfego
Policiador
CIR (bits/s)
CBS (bytes) Tráfego Excedente
S1-D1
Token Bucket
512000
8000
Descarta
S2-D1
Token Bucket
1024000
4000
Degrada Codepoint
S3-D1
Token Bucket
464000
4000
Degrada Codepoint
S4-D2
Token Bucket
512000
8000
Descarta
S5-D2
Token Bucket
1024000
4000
Degrada Codepoint
S6-D1
Token Bucket
464000
4000
Degrada Codepoint
Tabela 4.5 Características dos Policiadores
Estudo de Caso
96
Tipo de
CodePoint
Pmax
Minth (P kts) Maxth (P kts)
Gerenciamento
Tráfegos AF1.1 e AF1.2 (mesma classe AF)
EF
Drop - Tail
1
2
2
RIO
0.02
30
50
RIO
0.10
20
30
RIO
0.15
10
30
AF1.1 e
AF1.2
No Perfil
AF1.1
Fora do Perfil
AF1.2
PUC-Rio - Certificação Digital Nº 0016489/CA
Fora do Perfil
Tráfegos AF1 e AF2 em classes AF diferentes
AF1
No Perfil
AF1
Fora do Perfil
AF2
No Perfil
AF2
Fora do Perfil
RIO
0.02
20
40
RIO
0.1
10
20
RIO
0.02
20
40
RIO
0.1
10
20
Tabela 4.6 Características do Gerenciamento Ativo de Filas
Estudo de Caso
97
No sistema com buffer único (mesma classe), observa-se incialmente na Figura 4.17 as vazões efetivas em função da capacidade do enlace tronco, onde o
perfil contratado foi obtido para os agregados AF1.1 para o caso superdimensionado (4 Mbps). Pode-se notar que, o agregado AF1.1-FTP-Sack obteve taxa
superior ao AF1.1-FTP-Reno, na situação de congestionamento na faixa de 3
a 3.8 Mbps do enlace tronco, mostrando que usuários corporativos com diferentes implementações TCP, ainda que disputando banda sob mesma classe e
diferentes precedências de queda, alcançam taxas diferentes.
Vazão Efetiva (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
1100000
1000000
900000
EF1
800000
FTP_AF1.1_Reno
FTP_AF1.2_Reno
700000
FTP_AF1.1_Sack
600000
FTP_AF1.2_Sack
EF2
500000
400000
300000
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
4.0
Capacidade do Enlace (Mbit/s)
Figura 4.17 Vazão Efetiva dos Fluxos: AF por diferentes níveis de descarte
As simulações seguintes foram realizadas para avaliar os parâmetros que
influenciam as vazões efetivas dos agregados AF1.1 e AF1.2.
Começamos variando o parâmetro M axth da Tabela 4.6 para o agregado
AF1.1 fora do perfil numa faixa de 20 a 50 pacotes. Aumentado-se este limitante do buffer RIO dos agregados AF1.1 fora do perfil, permitimos que mais
pacotes fora do perfil dos agregados AF1.1 sejam encaminhados ao roteador
central. O resultado é apresentado na Figura 4.18.
Podemos perceber que ao permitir o encaminhamento dos pacotes AF1.1
fora do perfil promovemos o aumento das vazões efetivas destes agregados.
Em contrapartida, percebemos a degradação das vazões efetivas dos agregados
AF1.2, como era de se esperar, pois os agregados AF1.1 e AF1.2 disputam o
enlace de acesso de 2Mbps.
Nova simulação foi realizada variando dessa vez o parâmetro M axth para
Estudo de Caso
98
Vazão Efetiva (bits/s)
1100000
1000000
900000
FTP_AF1.1_Reno
800000
FTP_AF1.2_Reno
700000
FTP_AF1.1_Sack
600000
FTP_AF1.2_Sack
500000
400000
300000
20
25
30
35
40
45
50
Maxth buffer AF 1.1 (fora do perfil)
Figura 4.18 Vazão Efetiva dos Fluxos AF variando o buffer AF1.1 para pacotes fora do
os agregados AF1.2 fora do perfil, permitindo assim que mais pacotes fora
do perfil dos agregados AF1.2 fossem encaminhados ao roteador central. O
resultado é apresentado na Figura 4.19.
1000000
Vazão Efetiva (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
perfil
900000
800000
FTP_AF1.1_Reno
FTP_AF1.2_Reno
FTP_AF1.1_Sack
FTP_AF1.2_Sack
700000
600000
500000
400000
300000
10
15
20
25
30
35
40
45
50
Maxth AF 1.2 fora do perfil ( pacotes)
Figura 4.19 Vazão Efetiva dos Fluxos AF variando o buffer AF1.2 para pacotes fora do
perfil
Podemos perceber novamente que ao permitir o encaminhamento dos pacotes fora do perfil promovemos o aumento das vazões efetivas dos agregados
AF1.2. Em contrapartida, percebemos a degradação das vazões efetivas dos
agregados AF1.1 pois os agregados AF1.1 e AF1.2 disputam o enlace de acesso
Estudo de Caso
99
de 2Mbps.
Em última análise, as simulações confirmam que o encaminhamento de pacotes fora do perfil permite conseguir incrementos nas vazões. A diferenciação
de 2 tipos de tráfego pode ser feita, então, encaminhando mais pacotes fora do
perfil de um deles. Percebemos na Figura 4.18 que a partir de M axth igual a 25
(pacotes) o agregado AF1.1 começa a ter desempenho melhor que o agregado
AF1.2. Por outro lado na Figura 4.19 mostra que a partir de M axth igual a 20
(pacotes), o agregado AF1.2 começa a ter desempenho melhor que o agregado
AF1.1.
Agora, refazemos a simulação anterior variando o parâmetro Pmax da Tabela 4.6 numa faixa de 15 a 50 % , que é a probabilidade de descarte dos
agregados AF1.2 fora do perfil, permitindo assim que mais pacotes fora do
ao roteador central. Os resultados são apresentados nas Figuras 4.20 e 4.21.
Vazão Efetiva (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
perfil dos agregados AF1.2 fossem descartados antes de serem encaminhados
900000
880000
860000
840000
820000
800000
780000
760000
740000
720000
700000
680000
660000
640000
620000
600000
FTP_AF1.1_Reno
FTP_AF1.1_Sack
15
20
25
30
35
40
45
50
Pmax AF 1.2 fora do perfil (%)
Figura 4.20 Vazão Efetiva dos Fluxos AF1.1 variando Pmax AF1.2 para pacotes fora do
perfil
Percebemos que ao incrementar a probabilidade de descarte dos pacotes
fora do perfil de AF1.2 aumentamos a vazão efetiva dos agregados AF1.1 e
degradamos a vazão efetiva dos agregados AF1.2, porém, em ambos os casos
o fator de aumento ou de degradação não é superior a 10 Kbps.
Mostramos assim, que o parâmetro M axth do buffer RIO exerce influência
maior que o parâmetro Pmax na vazão dos agregados AF, principalmente para
Estudo de Caso
100
Vazão Efetiva (bits/s)
440000
420000
400000
FTP_AF1.2_Reno
FTP_AF1.2_Sack
380000
360000
340000
320000
300000
15
20
25
30
35
40
45
50
Pmax AF 1.2 fora do perfil (%)
Figura 4.21 Vazão Efetiva dos Fluxos AF1.2 variando Pmax AF1.2 para pacotes fora do
PUC-Rio - Certificação Digital Nº 0016489/CA
perfil
os agregados AF1.2. Porém devemos ressaltar qua avaliação por Pmax depende
da faixa de valores considerada. Em geral, probabilidades devem ser tratados
em escala logaritmica. Deve-se notar que o gerenciador ativo de fila RIO
descartada pacotes AF1.2 fora do perfil de acordo com o tamanho médio do
conjunto de todas as filas virtuais, no nosso caso, soma do tamanho médio das
filas AF1.2 no perfil mais soma do tamanho médio das filas AF1.1 e AF1.2
fora do perfil. Assim a influência dos parâmetros tende a ser menor.
No sistema com 2 buffers (diferentes classes), observa-se na Figura 4.22
as vazões efetivas em função da capacidade do enlace tronco, onde o perfil
contratado foi obtido para os agregados AF1 para o caso superdimensionado
(4 Mbit/s). Pode-se notar que, o AF1-FTP-Sack obteve taxa superior ao
AF1-FTP-Reno, na situação de congestionamento na faixa de 3 a 3.7 Mbps
do enlace tronco, mostrando que usuários corporativos com diferentes implementações TCP, ainda que disputando banda sob classes diferentes com iguais
precedências de queda, alcançam taxas diferentes.
Novas simulações foram realizadas no sentido de avaliar os parâmetros que
influenciam as vazões efetivas dos agregados AF1 e AF2. Percebemos no sistema com 2 buffers que o grau de diferenciação é facilmente associado aos pesos
do escalonamento WRR. Variando-se a relação entre os pesos usados para as
classes AF1 e AF2, obtém-se o gráfico da Figura 4.23.
Estudo de Caso
101
1200000
Vazão Efetiva (bits/s)
1100000
1000000
900000
EF1
FTP_AF1_Reno
FTP_AF2_Reno
EF2
FTP_AF1_Sack
FTP_AF2_Sack
800000
700000
600000
500000
400000
300000
200000
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
4.0
Capacidade do Enlace (Mbit/s)
Figura 4.22 Vazão Efetiva dos Fluxos: AF pela utilização de buffers diferentes
1200000
Vazão Efetiva (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
1100000
1000000
900000
800000
FTP_AF1_Reno
FTP_AF2_Reno
FTP_AF1_Sack
FTP_AF2_Sack
700000
600000
500000
400000
300000
200000
100000
1
1,5
2
2,5
3
3,5
4
Peso WRR (AF1/AF2)
Figura 4.23 Vazão Efetiva dos Fluxos: Influência do Peso WRR
Quando esta relação é igual a 2, levando-se em conta que o tráfego AF1
contrata aproximadamente o dobro da banda do AF2, dá-se o mesmo tratamento às 2 classes. Isto pode ser verificado observando-se que os valores da
vazão obtida pelos 2 tipos de tráfego (aproximadamente 900 Kbps e 350 kbps)
são proporcionais às taxas contratadas (1024 Kbps e 464 Kbps) significando
uma mesmo tratamento diante da falta de banda.
A partir deste ponto, observamos que variando a relação entre os pesos
podemos dar mais vantagem ao tráfego AF1 ou AF2 na utilização da banda
Estudo de Caso
102
disponível. Percebemos que o peso WRR atribuído para cada classe pondera a
quantidade de pacotes servidos, de forma que a quantidade de pacotes servidos
sempre será relacionada com a capacidade do enlace.
Avaliamos também o dimensionamento do buffer para diferentes classes,
inicialmente setados conforme a Tabela 4.6 com tamanho de 20 a 40 pacotes
para AF1 e AF2 dentro do perfil e de 10 a 20 pacotes para AF1 e AF2 fora
do perfil. Repetimos a simulação diminuindo a metade os parâmetros M inth
e M axth para as classes AF1 e AF2 dentro e fora do perfil. O resultado é
mostrado na Figura 4.24.
1200000
Vazão Efetiva (bits/s)
PUC-Rio - Certificação Digital Nº 0016489/CA
1100000
1000000
EF1
FTP_AF1_Reno
FTP_AF2_Reno
EF2
FTP_AF1_Sack
FTP_AF2_Sack
900000
800000
700000
600000
500000
400000
300000
200000
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
4.0
Capacidade do Enlace (Mbit/s)
Figura 4.24 Vazão Efetiva dos Fluxos: Influência do dimensionamento do buffer
Observarmos que ao diminuir os buffers das classes AF1 e AF2 para pacotes dentro e fora do perfil, os agregados AF1 e AF2 conseguem atingir suas
respectivas taxas contratadas a partir de 3.9 Mbit/s de banda do enlace tronco.
Porém na faixa de 3 a 3.8 Mbit/s de banda de enlace tronco (situação de congestionamento) observamos que os agregados AF1 e AF2, ambos TCP Sack,
têm vazão efetiva maior que os agregados AF1 e AF2 com implementação Reno.
Percebemos que o não dimensionamento correto dos buffers acarreta injustiça
na distribuição de banda, principalmente para implementação TCP Sack que
ao longo da simulações tem se mostrado eficaz em relação a implementação
TCP Reno.