Estimar o que você não consegue medir

Uma matriz de tráfego inferida dos contadores de enlace, o coletor de fluxo que decidi não construir, e os limites honestos do meu próprio laboratório

22 de agosto de 2026 Michel Wijnberg

O texto anterior parou uma pergunta antes, de propósito. O Osprey consegue lhe dizer que derrubar nrt1-cr1 ↔ sea1-cr1 muda 56 caminhos e não isola ninguém. A pergunta que um operador faz em seguida é a que decide se a mudança é segura:

Para onde vai o tráfego, e alguma coisa transborda?

Ninguém aprova uma mudança só com contagem de caminhos. O número que decide é capacidade: se os enlaces que herdam o tráfego têm espaço para ele. Este texto é sobre até onde dá para chegar honestamente perto desse número quando nada na rede o mede diretamente, e sobre onde essa resposta deixa de ser uma em que você deva se apoiar.

Respondê-la exige saber quanto tráfego flui de cada origem para cada destino: uma matriz de tráfego. Quase ninguém tem uma.

A coisa que decidi não construir

O jeito de manual de obter uma matriz de tráfego é a exportação de fluxo: NetFlow, sFlow, IPFIX. Os roteadores amostram fluxos, mandam registros a um coletor, e você os agrega em demandas origem-destino.

Eu planejei isso. Há um documento de projeto de 1.139 linhas neste repositório para um coletor de fluxo com deduplicação ciente do LSDB. Ele está marcado, na própria primeira linha:

Status: SHELVED (2026-03-12). Deferred indefinitely after cross-plan feasibility review.

com cinco motivos declarados. Os dois que de fato decidiram:

Volume. 70 a 220 GB por semana com 500 roteadores, aproximadamente cem vezes todo o resto do banco de dados. O PostgreSQL é o único armazenamento deste produto, de propósito; engolir um pipeline de fluxo significa ou um segundo armazenamento ou um banco de dados que cai.
Valor marginal. Cerca de 80% da visibilidade prática de tráfego já estava disponível pelos contadores de interface SNMP, que já vinham sendo coletados.

Isso não é uma impossibilidade técnica. É um julgamento de que os últimos 20% custam um subsistema novo, um fardo operacional novo e uma categoria de risco de armazenamento, e eu não achei que valesse a pena. Pessoas razoáveis discordam; algumas redes genuinamente precisam de fluxo. O que importa aqui é que a decisão está escrita com o raciocínio dela, para que quem avalia o Osprey possa conferir se a sua situação bate com a minha.

Então: sem registros de fluxo. O que deixa o problema interessante.

Inferindo a matriz a partir do que os enlaces admitem

O que o Osprey tem é a carga de cada enlace, medida direito: contadores de 64 bits ifHCInOctets / ifHCOutOctets, consultados em ciclo, diferenciados em bits por segundo, corrigidos para wrap, e divididos pela velocidade da interface para dar um percentual de utilização.

Isso é um conjunto de totais por enlace. O que você quer é um conjunto de demandas por par. Recuperar o segundo a partir do primeiro é um problema inverso subdeterminado: muitas matrizes de tráfego diferentes produzem exatamente as mesmas cargas de enlace. Existe uma abordagem bem conhecida: Tomogravity (Zhang, Roughan et al., 2003).

Ela funciona em dois movimentos, e o Osprey implementa os dois:

// computeTrafficEstimate estimates traffic redistribution after topology
// mutations using the gravity model (Zhang/Roughan et al., "Tomogravity" 2003).
//
// Without a full traffic demand matrix, per-pair demands are estimated using
// the gravity model: demand(i,j) ∝ V(i)·V(j)/V_total, where V(i) is the
// total traffic volume at device i (derived from SNMP interface utilization).
// These gravity demands are then calibrated against observed per-link loads
// so that the model's predictions match reality.

O passo gravitacional supõe que o tráfego entre dois roteadores é proporcional ao produto do quanto cada um carrega no total, o mesmo formato da gravidade newtoniana, ou de um modelo de comércio entre duas economias. É um a priori, não uma medição, e ele erra de maneiras específicas: não tem noção nenhuma de um par de vizinhos movimentado ou de um par quieto.

O passo tomográfico é o que o torna utilizável. O palpite gravitacional é escalado de modo que, quando toda demanda estimada é roteada pelos caminhos que o IGP de fato seleciona, as cargas por enlace resultantes batam com as cargas que foram medidas. O a priori é corrigido pela evidência, e a evidência é a única coisa aqui que não é palpite.

Aí, e só aí, as demandas calibradas são reroteadas pelos caminhos pós-falha (ponderadas por ECMP, de modo que um par cujo tráfego se divide em quatro contribui um quarto para cada enlace), e a diferença é a redistribuição projetada.

Três escolhas deliberadamente pouco impressionantes

Toda a engenharia interessante de um estimador está nos lugares onde você o impede de ser confiante.

Calibrar globalmente, não por enlace. A versão tentadora calcula um fator de escala para cada enlace de forma independente. Ela se ajusta melhor aos dados e é muito pior:

// Compute a GLOBAL calibration factor: total observed bps / total gravity sum.
// Per-link calibration can amplify noise when gravitySumPerLink is small
// relative to observed traffic, producing extreme scaling factors that
// inflate per-pair demands unrealistically. Global calibration distributes
// the error uniformly, producing more stable and realistic results.

Um enlace quieto com soma gravitacional quase zero e um pouquinho de tráfego medido produz um fator de escala enorme, que então infla todo par que o cruza. O ajuste mais apertado lhe compra absurdos ocasionais. Um fator global espalha o erro por igual e nunca explode.

Limitar qualquer par a 5% do volume total. Um teto rígido sobre quanto da rede uma demanda estimada pode representar, porque o modo de falha de um problema inverso é um par absorver tudo.

Recusar-se a reportar mudanças pequenas. Um deslocamento projetado menor que 0,5% da utilização do enlace é descartado, e 0,1% na via das mudanças de custo, que também carrega enlaces e nós hipotéticos e espalha finamente o efeito de um novo nó de trânsito por muitos enlaces. Abaixo disso, o número é indistinguível do tremor dos contadores, e imprimi-lo convida alguém a agir sobre ruído.

Cada uma dessas escolhas faz a saída parecer menos precisa. Precisão não é o objetivo; o objetivo é que um número mostrado na tela seja um número em que você possa se apoiar.

E agora a parte em que o meu laboratório não pode me ajudar

Tudo nos oito textos anteriores foi validado contra um laboratório capaz de me contradizer. 4.032 pares de roteadores conferidos contra tabelas de roteamento reais. 360 corredores fictícios encontrados. Três protocolos, três caminhos de descoberta, concordando sobre o mesmo ponto único de falha.

Para tráfego, o laboratório é quase inútil, e quero ser exato sobre o porquê.

Os roteadores deste laboratório encaminham quase nada. Eles rodam protocolos, trocam LSAs e atualizações BGP, e isso é essencialmente tudo. As medições:

Medição	Valor
Interfaces com dados de utilização	1.279
…abaixo de 0,05% de utilização	1.241
Maior utilização em qualquer lugar	0,431%, numa porta de 10 Mbps
Maior taxa de interface em qualquer lugar	~43 kbps
Pico entre as 368 interfaces classificadas como 10 Gbps	~24 kbps, ou seja 0,00024%

Dá para ver a consequência na captura de tela da simulação do texto anterior, se você souber onde olhar. O cabeçalho de enlaces derrubados diz “2 links, 6Kbps displaced”, seis kilobits, e o painel não mostra seção de Traffic Redistribution nem risco de congestionamento nenhum. Não porque o código não rodou. Porque todo deslocamento projetado ficou abaixo daquele piso de ruído de 0,5% e foi corretamente descartado.

O encanamento está verificavelmente certo: os contadores são lidos, as taxas são diferenciadas, as demandas gravitacionais são formadas, a calibração roda, a redistribuição é computada sobre os caminhos ECMP pós-falha, e o piso de ruído rejeita o que deve rejeitar. O que o laboratório não consegue me dizer é se a estimativa é boa, porque validar um estimador exige verdade de referência para comparar, e verdade de referência aqui significa tráfego real com uma matriz origem-destino conhecida.

Um laboratório sem tráfego não consegue produzir uma. Adicionar carga sintética também não resolveria: eu estaria gerando tráfego a partir de uma matriz que eu mesmo escolhi, e depois parabenizando o estimador por recuperar a matriz que eu acabara de lhe dar. Isso não é validação, é um jeito muito lento de testar a minha própria aritmética.

Então, quanto você deve confiar nisso?

Aqui está a escada honesta, na ordem em que os números vão ficando menos sólidos:

Utilização de enlace, ao vivo e histórica: medida. Contadores de 64 bits, diferenciados, corrigidos para wrap, conferidos contra a velocidade da interface. Isso é dado.
Quais caminhos mudam depois de uma mutação: computado a partir da topologia. Determinístico, e a topologia por baixo é aquela validada contra 4.032 pares de roteadores.
Quanto tráfego se move para cada enlace: estimado, a partir de um a priori gravitacional corrigido por cargas de enlace medidas. Útil em termos de direção, calibrado contra evidência real, e não uma medição.

O degrau 3 é genuinamente valioso. É a diferença entre “estes doze enlaces absorvem a falha” e “este único enlace absorve a maior parte e já está em 70%”. Também é o único degrau desta série inteira ao lado do qual eu não consigo colocar um número de validação, e seria desonesto apresentá-lo com a mesma voz de “4.032 de 4.032”.

O produto traça essa linha onde consegue. Quando o tráfego de um par BGP tem de ser derivado de proporções de contagem de prefixos em vez de uma interface SNMP casada, a linha carrega uma dica dizendo exatamente isso, “Traffic estimated from prefix count ratios (no SNMP interface match)”, ao lado de linhas marcadas com SNMP que vieram de contadores. A mesma tabela, graduada, que é o padrão em que esta série inteira insiste em aterrissar, e esta é a terceira vez que ele toma a mesma forma. Um caminho entre domínios gradua seus segmentos em resolved / inferred / opaque (quarto texto); uma anotação de porta gradua seus quatro veredictos, do fato declarado até a ambiguidade explícita (sexto texto); os três degraus acima graduam um número de tráfego. Três escadas, um hábito só: onde a evidência sob uma resposta é desigual, gradue no lugar em vez de emitir uma confiança única para a coisa toda.

Para que serve o laboratório, reafirmado

O sétimo texto argumentou que o laboratório não está ali para deixar o Osprey bonito, e sim para provar que o Osprey está errado. Este texto é o corolário de que ninguém gosta: um laboratório só pode refutar aquilo que é capaz de exercitar.

O meu é excepcionalmente bom em me contradizer sobre topologia, semântica de protocolo e encaminhamento, porque tem 192 roteadores reais com tabelas de roteamento reais que eu posso ler e comparar. Ele é incapaz de me contradizer sobre tráfego, porque não carrega nenhum.

Saber em qual dessas duas situações você está, para cada número que o seu produto imprime, é a maior parte do que separa uma ferramenta confiável de uma que é apenas confiante. Eu sei exatamente quais afirmações do Osprey são sustentadas por medição, quais por computação sobre um modelo validado, e quais por um estimador em que eu acredito mas não consigo provar aqui.

Este texto é a terceira categoria. Existe exatamente uma delas, e agora você sabe onde ela está.

A seguir, o último texto desta série: o modelo está correto, e ele também é um modelo do agora. Como a rede era uma hora antes de quebrar? A rede tem memória.