PRESENTATION DU DIFUSEUR

O propósito principal desta seção é estabelecer os procedimentos indispensáveis à J r correta operação do TCP Vegas conjuntamente com a rede DiffServ, visto que essa ? associação demanda ajustes específicos nos parâmetros do algoritmo RIO bem como nos

parâmetrosa e p. Tambémsão comparados os algoritmosTCP Vegas e TCP Reno e avaliada a interoperação dos mesmos.

6.3.1 MODELO DE SIMULAÇÃO

O modelo de rede empregado em todas as simulações tratadas na seção 6.3 (duas fontes) é o apresentado na figura 6.1. De acordo com a figura, há duas fontes (SI e S2) enviando dados a dois destinos (Dl e D2, respectivamente), dois roteadores de borda interligados porum enlace DiffServ que possui uma filado tipo RIO, e quatro enlaces com filas do tipo FIFO interligando as fontes e os destinos aos roteadores. Conforme mostra a

figura 6.1, o enlace DiflServ tem capacidade de 3 Mbps e retardo de 1 ms e cada enlace FIFO possui capacidade de 10 Mbps e retardo de I ms.

Esse cenário estabelece duas conexões, uma entre SI e Dl e outraentre S2 e D2, as quaisserãoreferenciadas daquipordiantesimplesmente como conexão da fonte SI e conexão da fonte S2, respectivamente (ou ainda conexão associada, ou relacionada, á SI e à S2, respectivamente). A velocidade de transmissão(configurada)decada fonte, para o tráfego em conformidade, pode variar de uma simulação para outra e, por isso, as mesmas são representadas por X e Y Mbps na figura6.1 para as fontesSi e S2, respectivamente.

Figura6.1-Modeloderede simulada.

6.3.2 Influência dosparâmetrosa e |3

O estudo desenvolvido nesta sub-seção tem por objetivo mostrar a influência que os parâmetros a e p têm sobre a distribuição de banda passante numa rede DiffServ. Nos simuladores aqui apresentados, o conjunto de parâmetrosRlO(out) são mantidos fixos para que apenas as variações causadas pelos dois referidos parâmetrospossam ser observadas.

Omodelosimuladocorrespondeexatamenteàquele da figura. 6.1, considerando-seduas fontes TCP Vegas com taxade transmissão configurada de 1 Mbps cada uma. As fontes SI e S2começam a transmitir nos instantes = 0 s et2 = 5 s, respectivamente; quantoaotempo de simulação, foram utilizados dois intervalos: de 0 a 30 s e de 0 a 100 s, os quais podem ser identificados pelas figuras correspondentes a cada simulação. A finalidade destes dois intervalos é facilitar a visualização da extensão dos resultados obtidos em cada caso.

Dessa forma, foram realizadas quatrosimulações, nas quaismanteve-seo RIOfout): 3-6 e variou-se os parâmetros « e pdeacordo com os valores citadosna seção 6.2. Os resultados obtidos são mostrados pelas figuras 6.2, 6.3, 6.4 e 6.5. Estas figuras apresentam: (a) banda passante alcançada pelas conexões associadas às fontes, (b) janela de congestionamento (CWND)de cadaconexão e (c) tempode ciclomedidopara cada conexão. O item(d)decada uma dessas figuras corresponde a uma ampliação do item (c) no instante de interesse de análise em quea fonte S2 começa a transmitir(na vizinhança det = 5 s). A seguir, faz-se a avaliação dos resultadosobtidosparaessasquatro simulações citadas.

6.3.2.1 Avaliação para ct=l e0-3

Analisando-seo resultado obtido para a=l e P=3 mostrado na figura 6.2a, pode-se observar que as conexões das fontes SI e S2não obtiveramvalores de bandapassante iguais conforme esperado, uma vez que a rede não estácongestionada c ambas as conexões são idênticas. Esse resultado está de acordo com o estudo realizado em [33] no qual é mostrado que esse problema de injustiça, quanto à distribuiçãode banda passante, é causado pelo fato deque com a<0 as CWNDs das conexões se mantêm fixas, como indicado na figura6.2b (a partir de t = 7s) e, em consequência, a bandapassante obtida por cada conexão se estabiliza num valor diferente uma da outra. Isso acontece porque os RTTs das conexões somente sofrem variações nosinstantes em queas fontes começam aenviar dados.

Portanto, conforme pode ser observado pelas figuras6.2c e 6.2d, no instante em que a

í +- s RTTsde ambas asconexões começam a variar

segundafonte entraem operaçao(t - 5 s), os Kl is ueamua.

e se mantêm assim até aproximadamentet = 6,7 s, o quefaz com que a CWND da fonte SI decresça atéotamanho de 3 segmentos (em função do aumentocmRTT!) e a CWND de S2 atinja 4 segmentos. A partirdesse instante o RTTde ambas as conexões se estabilizam, em torno de 18 ms, e então o algoritmo Vegasentende que não há congestionamento na rede e, porconseguinte, não altera mais o valor dasCWNDs (capítulo V, seção 5.4).

Ofato da segunda conexão obtermaiorbanda passante em relação à primeiratambém pode serexplicado com base noprincípio defuncionamento do TCP Vegas. De acordocom o

10 15 20 25 30 Tempo (s) a) Tempo (s) b) ---,— CWND1 --- CWND2 ---

1

:—

-

Figura 6.2 - TCP Vegascoma =1 e fl=3: a)Bandapassanteobtida pelas

b)Janeladecongestionamento

c) RTTsdas conexões d)RTTsno instante em que as

Tempo (s) d)

conexões dasfontesSIeS2

das conexões associadasa SIe S2

duasconexões começam a funcionarconjuntamente

que foi apresentado no capítulo anterior, no instante em que umaconexão TCP Vegas começa a transmitir, a mesma mede o RTT do primeiro segmento enviado a fim de determinar se a suaCWNDpode ser aumentada.

Dessaforma, comono instante em que S2 entra em operação a redesó possui a fonte SI transmitindo, o valor de RTT medido para a conexão da fonte S2 (RTT2) deve estar próximoao medido para a conexãoda fonteSI (RTT1),figuras 6.2c e 6.2d. Assim, a fonte S2 começa a transmitir e à medida que a mesma insere dados na rede, o RTT1 começa a aumentar e, em resposta, o algoritmo TCP Vegas de SI diminui a CWND1 causando uma redução na taxa de transmissão de Sl. Nesse ritmo, aCWNDI diminui até que o RTTdecada

conexãoatinja o equilíbrio apartirde t = 6,7 s. Deste ponto em diante o algoritmo TCPVegas infere que as CWNDs das conexões não devem ser alteradas e, assim, uma situação de estabilidade se instauraculminandono problema de injustiçacitado anteriormente.

Portanto, nessascondições pode-se dizer que o algoritmo TCP Vegas original, com os parâmetros a=l e 0=3, não provê justiça às conexões desta rede DiffServ. Em [33,52] os autores ressaltam que o TCP Vegas pode prover justiça adequada numa rede convencional, baseada no serviço de melhor esforço, fazendo-se cc-0. Nesse sentido, foram simulados aqui três conjuntos de parâmetros cc~fi a fím de se verificar a eficácia desta abordagem num ambiente DiffServ. As figuras 6.3, 6.4 e 6.5 apresentam osresultados para a=fi=l, a=fi=2 e

a=0=3, respectivamente; a avaliação de cada um destes casos são apresentadas nas sub­

seções seguintes.