Resumo

  • A RFC 1272 argumentou que os endereços IP das pontas não identificavam qual domínio administrativo adjacente transportou o tráfego através da fronteira de uma rede.
  • Medidores na fronteira poderiam apoiar a conciliação, mas o detalhe útil dependia da topologia, da granularidade, do armazenamento, do custo de coleta e da segurança.
  • O texto separou relatórios de uso de cobrança e aplicação de políticas, sem resolver se a contagem deveria ocorrer na entrada ou na saída do roteador.

O nome que faltava era o do vizinho

Um pacote IP carrega endereços de origem e destino. Isso permite contar tráfego entre as pontas, mas não informa, por si só, qual rede vizinha introduziu o pacote no domínio de um provedor. Se o tráfego de um mesmo sistema final pode chegar por domínios adjacentes diferentes, conhecer as pontas não responde à pergunta mais restrita do provedor: por qual rede este tráfego cruzou minha fronteira?

A RFC 1272 não queria que cada rede contabilizasse o uso de todos os usuários da Internet. Seu modelo se concentrava no domínio de uma administração e nos domínios diretamente conectados a ela. Um provedor poderia medir o tráfego que cruzasse a fronteira com um vizinho e trocar com ele um demonstrativo de uso. Se esse vizinho precisasse distribuir seus próprios custos mais adiante, isso seria responsabilidade dele. A contabilidade era recursiva: cada administração respondia pela relação que conseguia observar, sem fingir ter uma visão global do usuário final.

Essa distinção altera o lugar em que um medidor é útil. Um host observa o tráfego em uma ponta. Um roteador numa fronteira vê o tráfego entrando ou saindo do domínio local e pode fornecer evidência sobre uma interconexão adjacente. A RFC 1272 dizia que os cabeçalhos IP não continham, por si só, a identidade desse sistema intermediário; poderiam ser necessárias informações de camadas inferiores ou a configuração dos equipamentos de fronteira. Os endereços das pontas e a fronteira contábil respondiam a perguntas diferentes.

Medir também tinha um custo

A localização era apenas uma escolha. A RFC 1272 descrevia monitores dedicados, medidores de linha, medidores de software integrados ao roteador e conjuntos coordenados chamados “router spiders”. O local adequado dependia da topologia e do serviço medido. Medir na fronteira podia ajudar provedor e consumidor a comparar registros, mas não era uma ordem para instrumentar todos os roteadores.

O documento tratava o detalhe como uma escolha técnica e econômica. Um medidor poderia contar por porta, rede ou host, incluir atributos de pacotes, manter contadores ou horários e reportar em intervalos diferentes. Cada combinação de entidade e atributo podia exigir mais um registro de fluxo. Mais granularidade consome memória e processamento; relatórios mais frequentes usam banda e capacidade do coletor. Se a exigência for exatidão e confiabilidade completas, todos os pacotes precisam ser examinados. Para entender o comportamento, ajustar a rede ou estimar uma parcela de custos, a amostragem pode bastar por menos.

São padrões de evidência diferentes.

A coleta também precisava de proteção. Os autores tratavam dados de uso como sensíveis e apontavam confidencialidade, integridade e controle da coleta como preocupações. Discutiam confirmações com retransmissão, coletores redundantes ou armazenamento de reserva no medidor. Uma contagem obtida num roteador não se torna automaticamente um registro completo e confiável apenas por estar numa fronteira.

Um relatório não era fatura nem regra

A RFC 1272 limitava explicitamente seu objetivo. Era um texto informativo para uma arquitetura de relatório de uso, não um padrão da Internet. Relatórios poderiam ajudar um assinante a entender seu comportamento, um provedor a medir conformidade com políticas ou apoiar a alocação de custos. Mas reportar não bastava para aplicar uma política, e o documento não recomendava práticas de cobrança. Também não decidia quem deveria pagar por pacotes retransmitidos.

Uma pergunta ficou aberta: contar um pacote quando o roteador o recebe ou apenas quando o encaminha? Sob congestionamento, o roteador pode descartar pacotes. Contar na entrada captura os recursos consumidos pelo tráfego oferecido; contar na saída evita cobrar pelo tráfego que não foi encaminhado. A RFC 1272 exigia que a arquitetura comportasse as duas opções porque a escolha dependia do contexto e da política, não de uma regra técnica universal.

Mais tarde, a RFC 2722 especificou uma arquitetura de medição de fluxos. Esse trabalho posterior faz parte da história da medição, mas não prova a adoção de um modelo de cobrança específico nem de toda a visão contábil de 1991. A questão duradoura da RFC 1272 é mais limitada: o que uma administração pode saber na sua fronteira e quanto vale medir? É preciso preservar a cadeia entre fluxo observado, vizinho identificado, relatório e eventual decisão posterior de preço ou controle. Nada disso se deduz automaticamente dos endereços IP nas pontas.

Fontes: RFC 1272; RFC 2722; RFC 2990.