Resumo
- Anja Feldmann e outros cinco pesquisadores definiram uma demanda como volume que entra por um enlace e segue para um conjunto de saídas possíveis, sem confundi-la com a rota escolhida pela configuração daquele momento.
- No backbone IP da AT&T, o grupo combinou NetFlow, tabelas de encaminhamento, arquivos de configuração e validação SNMP; perda de coleta, estados defasados e entradas ambíguas permaneceram contabilizados.
Um enlace chega a 95% de utilização e parece encerrar o diagnóstico. Há um local, uma curva e um alerta. Mas o total não informa quais demandas se encontraram ali. Também não permite saber se a alteração de um peso OSPF aliviará o enlace ou apenas transferirá a sobrecarga para outro ponto.
Foi esse limite que orientou o trabalho conjunto de Anja Feldmann, Albert Greenberg, Carsten Lund, Nick Reingold, Jennifer Rexford e Fred True. A matriz de tráfego que estudaram não existia pronta em nenhum roteador. Ela surgiu da junção de registros distintos, cada um com alcance, tempo e falhas próprios.
A carga do enlace é uma consequência: demandas atravessam uma topologia sob uma configuração de rotas. A demanda é o que a rede recebeu para transportar. Se o efeito atual virar uma medida da própria demanda, a previsão de uma nova configuração ficará contaminada pela rota antiga.
Um conjunto de saídas preserva a pergunta
Uma matriz completa entre cada origem e cada destino teria dimensões enormes. Além disso, nenhum provedor enxergava toda a viagem: grande parte do tráfego cruzava vários domínios administrativos, e cada ISP observava apenas seu trecho.
Os pesquisadores escolheram uma representação compatível com esse limite. Cada demanda reunia o enlace de entrada, o volume e o conjunto de enlaces de saída capazes de alcançar o prefixo de destino. Uma retirada de rota BGP poderia mudar o conjunto. A configuração interna decidiria qual saída seria utilizada naquele instante.
Assim, uma mudança de OSPF não precisava redefinir a demanda; ela alterava o modo como a mesma demanda ocupava os enlaces internos. O NetScope, sistema relacionado criado por cinco integrantes da equipe, usava essa separação para localizar um enlace carregado, identificar as demandas que o atravessavam e testar outra configuração em simulação antes de alterar a rede operacional.
A escala de tempo também foi escolhida pela finalidade. Engenharia de tráfego opera com dezenas de minutos, horas ou dias, não com a ordem exata de cada pacote. Registros de fluxo podiam ser distribuídos em janelas e agregados por entrada e conjunto de saídas, preservando o necessário para explicar o impacto de uma decisão.
Medir menos pontos exige dizer mais sobre a incerteza
O desenho ideal coletaria dados finos em todos os enlaces de entrada. O fluxo forneceria interface, destino, início, fim e bytes. Tabelas de encaminhamento associariam o prefixo às saídas. Configurações descreveriam nomes, funções, capacidades, filtros e parâmetros OSPF. Um modelo de rotas verificaria o caminho possível.
Na rede da AT&T, nem todo acesso de cliente podia produzir a telemetria. Havia roteadores sem a função e casos em que habilitá-la consumiria recursos demais. A coleta concentrou-se então nos enlaces de peering, onde equipamentos mais capazes recebiam grande parte do tráfego entre provedores.
O compromisso deixou três lacunas. Tráfego interno entre acessos podia não aparecer em nenhum peering. Fluxos de saída eram vistos ao deixar a rede, sem revelar diretamente o acesso de origem. Trânsito multissalto podia ser registrado tanto na entrada quanto na saída e precisava ser reconhecido para não ser contado duas vezes.
Para um fluxo de saída, o endereço fonte indicava um ou mais acessos candidatos. O modelo perguntava, para cada um: com a topologia e as rotas daquela captura, esse caminho poderia chegar à interface de peering onde o fluxo foi observado? Candidatos incompatíveis eram eliminados.
Às vezes restava uma entrada; às vezes várias; às vezes nenhuma. Quando várias continuavam possíveis, o volume era dividido, em vez de ganhar uma origem inventada. A matriz guardava, portanto, estados diferentes: saída observada, entrada inferida de modo único, conjunto ainda ambíguo ou registro incompatível.
O coletor podia perder quase tudo sem ficar em silêncio
O NetFlow exportava registros por UDP. Nos períodos mais intensos, o enlace do servidor de coleta perdeu até 90% dos pacotes. A curva recebida ainda parecia uma curva de tráfego: subia e descia, apenas em escala errada. Um fluxo parcial pode ser mais enganoso que uma pane completa.
Os números de sequência expuseram os intervalos ausentes. O padrão era compatível com perdas aproximadamente independentes. A equipe estimou a probabilidade a cada dez minutos e aplicou um fator aos registros recebidos. Isso não reconstituiu os fluxos perdidos; extrapolou a amostra sob uma hipótese declarada.
Contadores SNMP forneceram a contestação externa. Eles mediam bytes por interface a cada cinco minutos. Depois da correção, a utilização reconstruída a partir do NetFlow acompanhou relativamente bem as séries SNMP. O SNMP não continha a matriz de entradas e saídas, mas testava se seu total por enlace fazia sentido.
Também era necessário conciliar identidades. NetFlow usava índices SNMP inteiros; configurações e tabelas usavam nomes e endereços. Relógios de algumas placas não estavam alinhados ao processador de rotas. E as quatro fontes eram capturadas em horários diferentes. Juntar linhas corretas de momentos incompatíveis produziria um estado de rede fictício.
Uma das quatro datas mostrou o problema. Um enlace de acesso havia sido atualizado depois da captura da configuração; uma tabela posterior já conhecia o substituto. Prefixos de clientes deixaram de combinar com a identidade antiga, elevando os registros não associados. Reconciliar a troca real reduziu a anomalia. O desencontro era evidência de mudança, não sujeira a ser apagada.
Quase todos os bytes não significam origem certa
Nos quatro experimentos de novembro de 1999, mais de 98% dos bytes vistos nos peerings geralmente foram associados a alguma forma de demanda. Para tráfego de saída, mais de 99,3% dos bytes tinham pelo menos uma entrada candidata. Ainda assim, cerca de 35% a 45% começaram com várias entradas possíveis.
O modelo de rotas removeu parte da ambiguidade. Aproximadamente um quarto a um terço desse volume convergiu para uma entrada única. Acessos redundantes do mesmo cliente na mesma cidade continuavam difíceis de separar e, muitas vezes, percorriam caminhos internos parecidos. No fim, cerca de 2,5% a 4% dos bytes de saída não se encaixaram em uma ou mais demandas ponto-multiponto.
Os valores pertencem a quatro dias de uma rede de 1999, não a uma referência atual. A contribuição duradoura é a separação entre cobertura e atribuição. Um cálculo pode incluir quase todo o volume e ainda não saber de maneira única onde parte importante dele entrou.
A análise encontrou concentração em poucas demandas grandes, variações ao longo do dia e alguma estabilidade entre as mais relevantes em dias consecutivos. Isso favorecia coleta seletiva, mas criava risco: se grandes demandas compartilhassem os mesmos enlaces, um erro de configuração ou uma mudança de comportamento teria efeito amplo.
A matriz precisava trazer suas condições de validade
O perfil científico de Feldmann reúne análise de tráfego, modelagem e roteamento porque nenhum desses elementos resolvia a questão sozinho. Um contador sem rota descrevia o efeito. Uma rota sem demanda medida calculava um mundo hipotético. Uma configuração sem tempo explicava com precisão uma rede que talvez já tivesse mudado.
A matriz era uma reconstrução datada, com correções, candidatos e resíduos. Essa imperfeição explícita a tornava mais útil que uma certeza artificial. Ela permitia perguntar de onde veio a carga, onde poderia parar após uma mudança e quais trechos da resposta eram observação ou inferência.
Esse continua sendo um bom teste para a observabilidade. Preserve o total bruto, mas também a versão das rotas, o estado da configuração, a perda da coleta, as correspondências de interface, os candidatos não resolvidos e a medição independente. O enlace vermelho indica o sofrimento. A cadeia de evidência indica se o remédio deslocará o problema.
Fontes
- Feldmann et al. — Deriving Traffic Demands for Operational IP Networks
- Feldmann e Rexford — IP Network Configuration for Intradomain Traffic Engineering
- Feldmann et al. — NetScope: Traffic Engineering for IP Networks
- Jennifer Rexford — Publicações
- Instituto Max Planck de Informática — Anja Feldmann
- DFG — Prêmio Gottfried Wilhelm Leibniz de 2011: Anja Feldmann
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
