Caracterização do Tráfego de Rede

• Queremos caracterizar quatro coisas nesse capítulo:
  • O fluxo de tráfego (de onde vem, para onde vai)
  • A carga de tráfego (para poder estabelecer capacidade de enlaces)
  • O comportamento do tráfego (considerações de broadcast, eficiência)
  • Considerações de qualidade de serviço (QoS)
• Com esta informação, poderemos escolher soluções adequadas no projeto lógico e no projeto físico da rede

Caracterização do fluxo de tráfego

• Identificações de fontes e sorvedouros de tráfego
• Identificação de direções e simetria
  • Exemplo: Uma aplicação cliente-servidor é tipicamente assimétrica, com o cliente enviando pouco e o servidor respondendo com muito
• Falaremos tanto da caracterização de tráfego na rede existente quanto da caracterização do tráfego das aplicações da rede nova

Identificação de fontes e sorvedouros principais

• Identificamos primeiro comunidades de usuários e locais de armazenamento maciço de dados
• Uma comunidade é um conjunto de usuários que utiliza as mesmas aplicações
  • Pode corresponder a um departamento ou conjunto de departamentos
  • Pode também cruzar fronteiras de departamentos
    • Exemplo: quando se formam times virtuais temporários numa empresa que utiliza "gerência em matriz" (alocação de times por projeto)
    • Neste caso, a divisão de comunidades é estritamente por utilização de aplicação e não por departamento
• Documentamos comunidades de usuários usando a tabela abaixo

• Precisamos identificar também grandes sorvedouros de dados, que são tipicamente onde dados são armazenados (data stores ou armazens de dados)
  • Servidor, server farm, mainframe, unidade de backup em fita, biblioteca de vídeo
  • Observe que tais sorvedouros poderão também ser importantes fontes de informação
• Documentamos os data stores usando a tabela abaixo

Documentação do fluxo de tráfego na rede existente

• Queremos identificar e caracterizar fluxos individuais de tráfego entre fontes e sorvedouros
• A RFC2063 (Traffic Flow measurement: Architecture) contém informação útil sobre este tópico
• Um fluxo individual comporta o tráfego de protocolo e de aplicação transmitido entre entidades durante uma única sessão
• Os atributos de um fluxo:
  • Direção
  • Simetria
  • Caminho (path)
  • Número de pacotes
  • Número de bytes
  • Endereços fonte e destino
• Pode -se identificar a quantidade de bytes de um fluxo usando um analizador de protocolos ou informação de uma estação de gerência de rede
• Coletando informação a partir de um ponto central da rede durante alguns dias, pode-se preencher a tabela abaixo
  • Um programa como traceroute (tracert) ou as próprias tabelas de roteamento podem ser usadas para descobrir as rotas

Caracterização dos tipos de tráfego para a nova rede

• Para novas aplicações, não podemos medir o tráfego na rede
• Temos que usar técnicas indiretas para caracterizar o tráfego
• Fundamental: precisamos entender como aplicações típicas se comportam (em termos de tráfego)
• Para ajudar na tarefa, usam-se Modelos de Fluxos bem conhecidos
  • Modelo termina-hospedeiro
  • Modelo cliente-servidor
  • Modelo peer-to-peer (par-a-par)
  • Modelo servidor-servidor
  • Modelo de computação distribuída
• Modelo de fluxo de tráfego terminal-hospedeiro
  • Fluxo assimétrico
  • O terminal manda alguns bytes e o hospedeiro responde com muitos bytes
  • Exemplo: telnet
  • Telnet pode mandar 1 byte por pacote do terminal para o hospedeiro
    • Mas também pode esperar um pouco e mandar muitos bytes
    • Para aplicações com linha de comando, pode-de ligar o eco local e mandar os bytes apenas ao digitar <ENTRA>
    • Para aplicações full-screen, não se pode esperar até o fim da linha
      • Uso de timeout para mandar vários caracteres de uma vez
      • A resposta desenha a tela
        • 1920 caracteres + caracteres de atributos + caracteres de posicionamento de cursor
        • Pode ser menos bytes com aplicações que desenham diferenças de tela
        • É assim para aplicações que usam o pacote libcurses no UNIX
        • É para saber como manipular a tela do terminal que se usa o comando "set term vt100"
• Modelo de fluxo de tráfego cliente-servidor
  • É o modelo mais aplicável hoje
  • É bidirecional e assimétrico
    • Tem dados nas duas direções (pedidos e respostas)
  • Pedidos pequenos e respostas maiores
  • Direção servidor ==> clientes é mais usada
    • Para muitas aplicações, pode-se considerar o fluxo unidirecional
  • O servidor é uma fonte de dados
  • Exemplo: a web moderna

• Modelo de fluxo de tráfego peer-to-peer
  • Usuários e aplicações são mais ou menos equivalentes nos seus requisitos de comunicação
  • Não tem direcionalidade óbvia
  • Exemplo: teleconferência onde todos os usuários participam e podem ser fontes e/ou sorvedouros
  • Exemplo: Internet antiga ondes todos faziam FTP e mail a partir de computadores centralizados (usando terminais burros e não PCs)

• Modelo de fluxo de tráfego servidor-servidor
  • Quando servidores conversam entre si
  • A simetria depende da aplicação particular
  • Exemplos:
    • Serviços de diretório
    • Cache de dados
    • Mirroring de dados para obter redundância e balanceamento de carga
    • Backup de dados
  • Exemplo final: computação cooperativa onde um trabalho é feito por várias máquinas comandadas por um hospedeiro gerente (ver figura)

• Modelo de fluxo de tráfego de computação distribuída
  • É o modelo mais especializado (e mais raro)

• Fluxos podem estar entre o manager e os nodos de computação ou entre os nodos de computação
  • Depende do acoplamento presente e da granularidade
• Com granularidade grossa e acoplamento fraco, temos um cluster de computação
  • Gerente aloca tarefas aos nodos
  • Comunicação entre gerente e nodos
  • Parece um modelo cliente-servidor
    • Porém os dados gerados no fim pelos nodos podem ser muito grandes comparados com a informação de inicialização enviada pelo gerente
    • Fluxo assimétrico mas no sentido contrário ao modelo cliente-servidor
  • Ver figura abaixo

• Com granularidade fina e acoplamento forte, temos um sistema de processamento paralelo
  • Tarefas são alocadas pelo gerente de tarefas aos nodos de computação
    os nodos trocam informação devido ao acoplamento forte
  • Entre todos os modelos, este tem os requisitos mais fortes de desempenho
  • O timing de transferência de informação é crítico porque as tarefas esperam pelos dados de outros nodos
  • Entre os nodos, não tem direcionalidade especial
  • Não tem fontes ou sorvedouros claros

Documentação do fluxo de tráfego na rede nova

• Para documentar os fluxos para aplicações existentes e novas, escolha o tipo de modelo, e identifique fontes e sorvedouros
• Use a tabela abaixo
  • Falaremos de requisitos QoS adiante
  • Os comentários pode dizer se a aplicação é full-screen, se é fortemente acoplada, etc.

Caracterização da carga de tráfego

• Queremos caracterizar a carga de tráfego para o correto planejamento de capacidade dos enlaces
• É muito difícil ter uma idéia precisa da carga de tráfego, mas queremos tentar evitar gargalos na rede final

Cálculo da carga teórica de tráfego

• Na teoria, as coisas são relativamente simples
• Para calcular a carga, precisamos saber:
  • O número de estações que geram tráfego
  • O tempo médio entre quadros gerados
  • O tamanho médio dos quadros transmitidos
• Alguns parâmetros adicionais que podem ajudar a levantar a carga:
  • A frequência de sessões de aplicações
  • O tempo médio de cada sessão
  • O número de sessões simultâneas
• O problema é justamente estimar todos esses parâmetros!
• Tem que conhecer as aplicações e fazer estimativas
• Pode-se usar ferramentas de modelagem de redes que possuem conhecimento embutido de certos tipos de aplicações e permitem parametrizar o modelo interno
• A tabela abaixo pode ajudar a ter uma noção do tamanho de objetos trocados numa sessão de trabalho

• Mostraremos um exemplo real de estimativas de tráfego adiante

Incluindo o overhead de protocolos

• Deve-se adicionar o overhead devido a protocolos usados pelas aplicações
  • A tabela abaixo ajudará a fazer as estimativas

Estimativas de carga de tráfego de protocolos de roteamento

• Protocolos de roteamento adicionam overhead de tráfego
• Calcular o overhead é especialmente importante para estimar o tráfego adicional num enlace WAN lento
• Os protocolos de roteamento ainda não foram escolhidos mas a tabela abaixo fornece uma idéia do overhead

Um exemplo

• Rede SEFIN conectando a sede, Superintendências Regionais, Coletorias e Postos Fiscais
• Só importa o levantamento de tráfego na WAN para caracterizar os enlaces WAN
  • A LAN é de 100 Mbps na sede e não há tráfego pesado
  • A LAN é de 10 Mbps nas SNRs e PFs e não há tráfego pesado
• Topologia da WAN

• Topologia de uma SNR

• A planilha de tráfego está aqui
• Reproduzimos algumas planilhas abaixo
• Parâmetros usados

• Fluxos individuais
  • Observe como a capacidade do enlace é calculada levando em consideração atraso razoável e vazão

• Fluxos consolidados

• Resumo
  • Observe a assimetria dos fluxos
  • A maioria das tecnologias de rede é simétrica, mas algumas (ADSL, p.ex.) são assimétricas

Caracterização do comportamento do tráfego

• Para caracterizar tráfego, não basta entender os fluxos normais das aplicações
• É necessário entender o comportamento das aplicações com respeito a atividade de broadcast

Comportamento broadcast e multicast

• Um quadro de broadcast vai para todas as estações do domínio de broadcast
  • Endereço MAC FF:FF:FF:FF:FF:FF
• Um quadro multicast (mais raro) vai para todas as estações que participam de um grupo de broadcast
• Dispositivos de interconexão de camada 2 (pontes e switches) propagam broadcast em todas as portas
• Isso leva a problemas de escalabilidade
  • Broadcast demais deixa as CPUs com muito overhead de processamento
  • 100 quadros de broadcast por segundo afeta o desempenho de um Pentium
  • Broadcast deve ser limitado a 20% do tráfego total
• Broadcast é necessário
  • Muitos serviços de redes locais precisam de broascast
    • DHCP, ARP, SAP, NETBIOS, RIP, IGRP, ...
• Domínios de broadcast são delimitados por:
  • Roteadores (eles não propagam broadcast)
  • LANs virtuais (VLANs) em switches de camada 3
• A tabela abaixo pode ser útil para determinar quantas estações colocar num único domínio de broadcast

Caracterização de requisitos de Qualidade de Serviço

• Além da carga de tráfego, precisamos saber se algumas aplicações possuem restrições quanto à inflexibilidade da vazão ou do atraso
• Caracterizamos portanto o QoS (Quality of Service) dos fluxos das aplicações
• Podemos usar dois modelos para caracterizar QoS
  • Categorias de serviço ATM
  • Modelo do Integrated Services Working Group da IETF

Especificação de QoS ATM

• Você pode caracterizar os requisitos de QoS usando as categorias ATM
  • CBR - Constant Bit Rate
    • Emula um fio
    • Sem controle de erro ou controle de fluxo
    • Para voz (telefone) e fluxos de áudio de alta qualidade e fluxos de vídeo
  • RT-VBR (Real-Time Variable Bit Rate)
    • Para vídeo comprimido interativo (vídeoconferência)
    • Compressão MPEG manda quadro completo seguido de quadros diferenciais
      • Mudança drástica de taxa de transmissão (VBR)
      • Fortes restrições no atraso e na variabilidade do atraso (RT)
  • NRT-VBR (Non Real-Time Variable Bit Rate)
    • Sem restrições de atraso e variabilidade de atraso
    • Exemplo: Email multimídia será visto off-line (não em tempo real)
  • ABR - Available Bit Rate
    • Tráfego em rajadas mas com banda passante mais ou menos conhecida
    • Exemplo: quero 5 mbps no mínimo mas usarei 10 mbps de vez em quando. Quero garantia dos 5 mbps mas aceito se não receber 10 mbps garantidamente
    • Usa feedback para pedir à fonte diminuir o ritmo se houver congestão
  • UBR - Unspecified Bit Rate
    • Sem promessas, sem feedback sobre congestão
    • Apropriado para IP (que não garante nada) e para aplicações como ftp, email, ...
• Parãmetros podem ser usados para especificar os requisitos