Discussão

para cada ponto, utilizando sementes diferentes para os números aleatórios. Em alguns casos, os intervalos de confiança são tão pequenos que não se distinguem do próprio ponto correspondente à média.

[Floyd 01]: o tempo de processamento gasto por processos Unix; o tamanho de ficheiros Unix, tramas de vídeo comprimidas e objectos WWW; e rajadas de actividade Ethernet e FTP.

Este estudo [Floyd 01] ainda refere que as correlações de longo prazo nas chegadas de pacotes observadas no tráfego agregado na Internet são bem modeladas por processos fractais, ou auto-similares (self-similar). Isto significa que o tráfego parece semelhante em diferentes escalas de tempo. Uma forma possível de gerar tráfego com propriedades fractais é [Paxson 95] multiplexar tráfego de fontes OnOff com ritmo fixo nos períodos On e períodos tirados de uma distribuição com cauda pesada.

Desta forma, as simulações realizadas, por utilizarem principalmente a distribuição exponencial, correspondem a uma aproximação simplificada da realidade da rede Internet. No entanto, procurou-se utilizar diversos tipos de fontes de tráfego de forma a melhor aproximar o funcionamento de uma rede real.

Outro aspecto tem a ver com a distribuição de protocolos utilizada, que também não corresponde exactamente à situação real. A tabela 5.4 [Edell 99] indica a distribuição por protocolo do tráfego dos utilizadores num ISP e no sistema INDEX. A primeira coluna indica a classificação do protocolo de acordo com a utilização no ISP.

A terceira coluna é a percentagem do volume de tráfego por protocolo para o ISP, e a quarta coluna para o sistema INDEX. O sistema INDEX é um ISP experimental usado para investigação na universidade da Califórnia em Berkeley. Da comparação dos dois sistemas, verifica-se que as quatro aplicações mais utilizadas no ISP (WWW, News, email e FTP) correspondem a 96% do tráfego, enquanto os utilizadores do INDEX utilizam uma gama mais larga de protocolos. Isso pode ser explicado pelo facto de os utilizadores do INDEX serem mais experientes.

Também os ritmos usados nas simulações não correspondem aos ritmos da Internet actual. Na realidade, o núcleo da rede de alguns operadores chega a ter linhas OC-192c a 10 Gbps, prevendo-se 40 Gbps para 2002 [Liu 01], sendo natural que os ritmos continuem a aumentar com a vulgarização da tecnologia WDM (Wavelength- Division Multiplexing) [Ryan 98]. Além disso, com acessos por Digital Subscriber Line (DSL), muitos utilizadores individuais já têm ritmos superiores a 64 Kbps, sendo os ritmos muito superiores para empresas. Também nas redes locais os ritmos de 100 Mbps são normais, estando já disponível a Ethernet a 1 Gbps e a norma da Ethernet a 10 Gbps em preparação [Baritault 00].

Lugar Protocolo ISP (%) INDEX (%)

1 HTTP 76 43

2 NNTP 12 2

3 POP3 3 3

4 FTP 3 11

5 SMTP 2 0.5

6 HTTPS 2 2

18 Telnet/SSH 0 4

Não Disponível X-Windows Não Disponível 2

Tabela 5.4: Distribuição da utilização de protocolos num ISP e no sistema INDEX.

No entanto, o mais importante é manter uma certa relação entre os ritmos nas ligações e nas linhas do núcleo da rede, e não tanto os valores absolutos destes ritmos. A utilização de ritmos superiores tem como principal efeito exigir uma maior capacidade de processamento e mais memória para guardar informação. Todo o processamento será semelhante, havendo apenas um maior número de eventos a processar por unidade de tempo. Assim, será possível fazer simulações utilizando ritmos relativamente baixos, sem perder generalidade, desde que os tempos de resposta aos eventos e as durações das simulações sejam ajustados de acordo com os ritmos de ocorrência de eventos na rede.

Relativamente à duração das simulações, verificou-se que, configurando as simulações para começar com uma carga inicial correspondente ao valor pretendido para o tráfego oferecido, o período transitório no início das simulações era muito pouco significativo, pelo que se obtinha praticamente os mesmos resultados simulando apenas um minuto de tempo real, ou fazendo uma simulação mais longa. Na realidade, sendo o efeito do transitório inicial desprezável, o que influi nos resultados é principalmente o valor médio do tráfego oferecido à rede, que se fez constante em cada simulação. Assim, optou-se por fazer simulações de apenas um minuto de tempo real, variando-se a carga de simulação para simulação, de forma a analisar diferentes situações de carga. Isto significa que os tempos de reacção de algumas políticas activas têm de ser mais curtos do que na realidade seriam, para que se possa observar o seu efeito. Para os casos em que se utilizaram políticas activas de planeamento, fizeram-se simulações mais longas, de três minutos de tempo real, de forma a que as políticas activas tivessem tempo de reagir eficazmente. Também neste caso se verificou que os resultados obtidos eram

semelhantes aos de uma simulação mais longa, não se justificando alongar mais as simulações.

Foram feitas outras simplificações na simulação. Por exemplo: o tempo está sempre sincronizado em todos os nós da rede, visto ser o tempo do simulador. Num sistema real, esta propriedade pode ser obtida, tal como sugerido em [RFC 2330], pela utilização do protocolo NTP (Network Time Protocol), o que pode ser importante, por exemplo, para a medição de atrasos unidireccionais. Outra simplificação advém do facto de não haver nenhum protocolo de sinalização com os corretores de largura de banda.

Isto significa que o tráfego correspondente é desprezado em face do tráfego de dados.

Também não é simulado o tráfego de comunicação entre as políticas activas. O cenário que mais se aplica a estas decisões é as políticas activas estarem colocadas junto aos equipamentos que monitorizam, de forma a não utilizarem largura de banda da rede, e as notificações que enviam entre elas, por serem raras, poderem ser desprezadas face ao tráfego de dados. Em termos de largura de banda, estas simplificações podem ser anuladas sobredimensionando a capacidade da rede ligeiramente, para levar em conta estes tipos de tráfego. Para além disso, em termos de tempo, numa rede real vai haver também atrasos na transmissão do tráfego de gestão que podem causar problemas. Uma forma de minimizar os seus efeitos seria enviar as notificações de problemas, a que se tivesse de reagir rapidamente, como tráfego de prioridade máxima, desde que tal seja suportado pela rede. No entanto, esses atrasos na transmissão devem ser sempre muito menores do que o tempo que o sistema demora a evoluir, de forma a que se possa reagir a tempo e no sentido correcto.

Recorde-se, para terminar, que o foco deste trabalho está em testar as potencialidades de uma infra-estrutura de gestão baseada em políticas activas, a metodologia necessária à sua implementação, e assim validar o modelo proposto nesta tese. Os impactos das simplificações realizadas devem ser vistos nesta perspectiva e não numa perspectiva de fidelidade estrita do cenário à realidade da Internet.