Resumo

  • A arquitetura experimental de janeiro de 1997 permitia que o medidor continuasse acumulando tráfego durante uma falha do leitor. A recuperação dos totais dependia da continuidade e da disponibilidade desse estado; as coletas perdidas reduziam a resolução temporal. RFC 2063, §2.5.
  • Regras, identidade do fluxo e retenção determinavam o que ainda seria interpretável na retomada. Leitores redundantes protegiam a continuidade da coleta; medidores redundantes no mesmo segmento protegiam a medição. RFC 2063, §§2.5, 3.2 e 4.5.

O intervalo que fica sem registro

Num cenário hipotético, o programa leitor para enquanto o medidor segue contando. Na retomada, encontra uma contagem maior que a última que havia guardado. Se as regras permaneceram iguais, o registro corresponde ao mesmo fluxo, o estado foi retido e não houve retorno do contador a zero que torne a diferença ambígua, é possível apurar o aumento entre as duas leituras. O mesmo aumento, porém, poderia resultar de tráfego distribuído ou de uma concentração breve. Essa conclusão analítica decorre da perda de coletas intermediárias reconhecida na seção 2.5 do RFC 2063.

Em janeiro de 1997, Nevil Brownlee (The University of Auckland), Cyndi Mills (BBN Systems and Technologies) e Greg Ruth (GTE Laboratories, Inc.) apresentaram o RFC 2063 como ponto de partida para o trabalho de medição de fluxos em tempo real (RTFM) da IETF. Experimental e sem condição de padrão da Internet, o documento organizava informações, requisitos e escolhas de implementação, sem especificar um protocolo. RFC 2063, apresentação e §1.

Quem guarda cada parte da evidência

O fluxo era uma construção lógica: regras reuniam pacotes observados em uma parcela de tráfego com início, fim e uma entidade à qual se atribuía o uso. Como os pacotes IP são independentes, essa associação dependia dos atributos escolhidos. A entidade podia ser usuário, máquina, rede ou grupo de redes, sem identificação automática de um pagador contratual. Cada pacote era contabilizado em um único fluxo; análises sobrepostas exigiam agrupamentos mais finos e disjuntos, combinados posteriormente. RFC 2063, §§2.1 e 3.3.

O gerente configurava regras, detalhamento, amostragem, limites da tabela e inatividade. Também definia quais medidores, intervalos, fluxos e atributos o leitor consultaria. O medidor guardava contagens cumulativas de pacotes e bytes, além dos horários do primeiro e do último pacote. Ao leitor cabia transportar os dados de forma confiável e armazenar arquivos por medidor, com identificação, horário, regras de coleta, descritores e contagens. Essas funções podiam compartilhar uma máquina; a aplicação de análise derivava taxas das observações. RFC 2063, §§2.1–2.4, 3.1 e 5.2.

Na retomada, endereços iguais não bastavam para estabelecer continuidade: o horário de início do fluxo, seu contexto e o Rule Set ID ajudavam a distinguir um registro preservado de outro recém-criado. A recomendação de manter contadores cumulativos, sem zerá-los na leitura, permitia cobrir registros de uso perdidos com valores posteriores. Somar totais sucessivos como tráfego novo duplicaria contagens. Os horários extremos de atividade tampouco revelariam a sequência dos pacotes dentro da lacuna — uma limitação deduzida dos dados disponíveis. RFC 2063, §§3.1–3.3 e 5.2.

A memória também impõe um prazo

O RFC 2063 exigia que ao menos um leitor coletasse um fluxo sem atividade antes da liberação de sua memória. LastCollectTime e controles de inatividade orientavam essa decisão; a política de mínimo ou lista de leitores necessários ainda demandava desenvolvimento. Sob pressão de memória, regras de reserva menos detalhadas e coletas mais frequentes podiam ajudar. O texto admitia pequenas perdas para manter o medidor funcionando. A recuperação, portanto, dependia do estado efetivamente disponível, sem promessa de retenção ilimitada. RFC 2063, §§3.2, 4.5–4.6 e 5.3.

A natureza da falha importava. Sem gerente, esperava-se que medição e coleta prosseguissem. Uma parada controlada do medidor podia motivar coleta final; um reinício inesperado podia ser comunicado ou descoberto pela consulta do leitor, seguido da recarga das regras. Por dedução, essa recarga não recuperaria tráfego não medido ou estado desaparecido. As notificações propostas também não constituíam garantia de entrega. RFC 2063, §6.3.

Leitores independentes, observações diferentes

Era possível ler a tabela inteira, linhas ou apenas atributos, sem sincronizar coletas. Dois leitores com intervalos iguais, mas coletas em instantes diferentes, tenderiam a produzir registros distintos; a divergência isolada não demonstraria corrupção. Registros cumulativos sobrepostos precisariam ser comparados, evitando somá-los como volumes adicionais. A redundância de leitores preservava oportunidades de coleta, enquanto medidores redundantes no mesmo segmento protegiam contra a falha de um medidor. RFC 2063, §§2.2 e 2.5.

A MIB experimental contemporânea, no RFC 2064, permitia varreduras independentes mediante índices sem estado de leitura compartilhado. TimeFilter e GetBulk facilitavam buscar linhas alteradas e atributos. A passagem começava pela escrita de flowReaderLastTime; flowReaderPreviousTime auxiliava a liberação de memória, e flowReaderTimeout permitia excluir o cadastro de um leitor após atraso excessivo. O início da passagem não representava uma captura atômica da tabela inteira. O RFC 2064 já admitia um recorte estável pela troca para outro conjunto de regras idênticas no mesmo medidor. Falhas de escrita ou autenticação podiam bloquear a liberação mesmo quando a leitura continuava possível. RFC 2064, §3.2 e tabela de informações dos leitores.

O esclarecimento posterior tem data

O RFC 2063 previa um gerente controlador por medidor e por leitor; a MIB do RFC 2064 já distinguia um gerente principal. A revisão informativa RFC 2722, que substituiu o RFC 2063 em outubro de 1999, admitiu conjuntos de regras concorrentes para diferentes gerentes, preservando um gerente por leitor. Manteve a perda de resolução temporal nas falhas do leitor e esclareceu a espera por todos os leitores cadastrados antes de liberar memória, além da exclusão de cadastros por tempo limite. Também detalhou a alternância entre dois conjuntos idênticos em um medidor para obter registros idênticos do conjunto anterior, sem garantir troca simultânea em vários medidores. São formulações documentais distintas, não comprovação de implantação dessas condições em 1997. RFC 2063, §§2.3–2.4; RFC 2064, §3.2; RFC 2722, §§2.3–2.5 e 4.5.

A arquitetura deixava tarifas fora do escopo, não fixava o transporte e atribuía aos protocolos de coleta e gerência a proteção da integridade e da confidencialidade. Seus registros de volume, por si, não estabeleciam autorização de cobrança, validade de fatura, entrega útil ou pagamento. O ponto central permanecia temporal: conservar uma quantidade podia sustentar um total sem sustentar a mesma precisão sobre quando o tráfego ocorreu. RFC 2063, §§1, 2.5, 5.3 e 10.

Fontes e limites da leitura

Documentação de 1997: RFC 2063 — arquitetura e condições de recuperação; RFC 2064 — MIB do medidor, coleta e retenção.

Situação documental: RFC 2063 — registro oficial da condição experimental e da substituição pelo RFC 2722; RFC 2063 — consulta oficial de erratas. A ausência de uma errata não comprova perfeição. A publicação e suas revisões, por si, não demonstram adoção atual nem compatibilidade de produtos.

Antecedente e revisão: RFC 1272 — fundamentos da medição e separação entre medição e recuperação de custos, de novembro de 1991; RFC 2722 — revisão informativa da arquitetura e RFC 2720 — MIB posterior do medidor, ambos de outubro de 1999. Esses dois últimos documentos fornecem contexto posterior, sem substituir a descrição de 1997.

Lentes editoriais posteriores: Lu Heng distingue publicação de realidade adotada em seu ensaio sobre a primazia do código em funcionamento. Seu ensaio sobre especificação mínima, decisões locais e adoção voluntária oferece uma lente para separar significados comuns de escolhas operacionais e comerciais. Em sua reflexão sobre a finalidade da BTW.Media, propõe descrever estruturas e pressupostos em vez de promover soluções. Aplicadas aqui à coleta e à retenção, são interpretações posteriores atribuídas a Lu Heng, sem comprovar comportamento técnico ou intenções dos autores de 1997.