Resumo

  • A RFC 9808 padroniza dois objetos complementares: FCI.CapacityLimits, para os limites de capacidade divulgados por uma CDN downstream, e FCI.Telemetry, para identificar as medições de utilização associadas.
  • O limite serve de insumo para a CDN upstream decidir quanto tráfego delegar. O próprio padrão afirma que a informação é consultiva: não é garantia, compromisso ou reserva, muito menos prova de que uma requisição foi aceita e entregue.

Imagine uma janela de operação em que o tráfego cresce depressa. Às 20h, a CDN downstream divulga margem no limite de saída. O sistema upstream vê utilização confortável e aumenta a delegação. O número pode estar correto e, ainda assim, a decisão falhar: a medição resume os cinco minutos anteriores, chega com atraso e não mostra que o limite de sessões já encostou no máximo.

Esse não é um defeito lógico da capacidade anunciada. É um erro de categoria na leitura. Um envelope descreveu até onde o tráfego não deveria avançar; ele não separou recursos para uma contraparte específica nem emitiu um recibo de admissão.

A RFC 9808, publicada na trilha de padrões em julho de 2025, estende a interface de anúncio de footprint e capacidades do CDNI. Andrew Ryan, Ben Rosenblum e Nir B. Sopher aparecem como autores no registro do RFC Editor, enquanto o Datatracker do IETF conserva o status e o histórico do documento.

Os dois novos objetos têm funções diferentes. FCI.CapacityLimits enumera limites que a CDN downstream considera aplicáveis ao tráfego delegado. FCI.Telemetry informa fontes e métricas pelas quais a CDN upstream pode observar a utilização corrente. O registro de parâmetros CDNI da IANA lista os dois tipos de payload, uma fonte genérica de telemetria e seis tipos iniciais de limite.

O padrão não esconde sua fronteira jurídica e operacional: a informação é advisory e não representa garantia, compromisso ou reserva de capacidade. Portanto, nem uma assinatura válida, nem um objeto bem formado, nem uma leitura abaixo do máximo alteram automaticamente a relação comercial entre as partes.

Essa separação já está no desenho do CDNI. O problema de interconexão descrito na RFC 6707 permite que uma CDN autoritativa ou upstream encaminhe parte das requisições a uma CDN downstream. Os acordos comerciais entre provedor de conteúdo, upstream e downstream ficam fora da especificação técnica. Um campo interoperável pode reduzir ambiguidade operacional sem criar, por si só, preço, prioridade, crédito ou indenização.

A arquitetura da RFC 7336 também separa anúncios assíncronos do atendimento síncrono de cada requisição. Escolher redirecionar continua sendo uma decisão local da upstream. A RFC 9808 fornece evidência melhor para essa escolha; não assume o controle dela.

O primeiro cuidado é o escopo. Cada limite vale para o footprint do anúncio que o contém. Um valor relativo a determinado prefixo, ASN, país ou outra área registrada não pode ser tratado como teto da rede inteira. A RFC 8008 usa footprint e capacidade para delimitar candidatas ao encaminhamento, não para prometer alcance universal.

O segundo cuidado é a conjunção. Quando vários limites se aplicam, a upstream deve lê-los com um AND lógico. Não é permitido escolher a dimensão mais folgada e ignorar as demais. A saída pode ter margem enquanto requisições por segundo, objetos armazenados, sessões ou cache atingem a fronteira. Os seis tipos registrados — saída, requisições, tamanho de armazenamento, quantidade de objetos, sessões e tamanho de cache — descrevem um envelope multidimensional.

Cada entrada exige maximum-hard, o máximo de capacidade disponível para uso. Pode incluir também maximum-soft, sempre menor, a partir do qual a upstream deveria reduzir tráfego antes de chegar ao teto duro. Sem o valor suave, ele coincide com o duro.

O adjetivo “duro” costuma produzir uma segurança que o protocolo não oferece. Ele diferencia dois patamares dentro da declaração da downstream; não afirma que o patamar superior foi isolado para aquela upstream. “Disponível para uso” tampouco significa que o mesmo estado existirá quando uma requisição futura chegar ao ponto de admissão.

A telemetria impede que o limite fique solto de sua definição. Uma fonte tem identificador estável, tipo, métricas expostas e configuração opcional. Cada métrica possui nome estável dentro da fonte. Um limite pode apontar para o par fonte–métrica, permitindo verificar se capacidade e utilização realmente usam a mesma unidade e a mesma semântica.

Três campos opcionais mudam a interpretação. time-granularity informa o intervalo resumido; data-percentile indica um percentil e, quando ausente, o valor corresponde à média; latency expressa quanto a observação fica atrás do tempo real. Uma medição pode ser matematicamente correta e operacionalmente velha demais para autorizar uma aceleração agressiva.

“Quase em tempo real”, portanto, não é sinônimo de “agora”. Uma média de cinco minutos recebida 25 minutos depois descreve um passado diferente de uma média de um minuto com poucos segundos de atraso. Os dois formatos podem obedecer ao esquema. Só um deles talvez caiba no intervalo de controle escolhido pela upstream.

A RFC admite um valor current dentro do próprio anúncio para casos simples, mas não recomenda carregar ali a utilização que muda rapidamente. Respostas de capacidade precisam ser cacheáveis; a utilização pede consulta mais frequente. O modelo preferível combina um envelope relativamente estável com uma fonte separada de telemetria.

O envelope também envelhece. Sua validade herda o TTL do transporte, como o Cache-Control HTTP. Se não houver mecanismo de TTL, as partes devem combinar a duração fora de banda. Um limite ainda pode estar formalmente válido e, ao mesmo tempo, ser uma referência ruim para um pico súbito.

Há ainda o problema da agregação. Quando uma upstream delega tráfego por várias downstreams e depois informa seu uso total, deve incorporar o consumo delegado. Caso contrário, o tráfego terceirizado some do painel sem desaparecer da rede, da capacidade ou do custo. O objeto de telemetria torna essa contabilidade especificável, mas não certifica que todos os sistemas a implementaram.

Outras interfaces CDNI produzem recibos distintos. A RFC 8007 define gatilhos para preposicionamento, invalidação e purga, com estados próprios. Um gatilho concluído não é anúncio de capacidade; um anúncio de capacidade não prova a execução do gatilho. A RFC 8006 distribui metadados de conteúdo, sem equiparar o recebimento desses metadados à aquisição ou à entrega do objeto.

Uma operação auditável deve preservar uma sequência, não apenas um painel:

  1. a RFC e a IANA definem nomes e semântica comuns;
  2. uma resposta FCI declara um envelope para um footprint e uma validade;
  3. uma fonte mede utilização sob método, janela e atraso identificados;
  4. a upstream concilia todos os limites e decide quanto delegar;
  5. a downstream admite, posterga ou recusa cada requisição sob estado vivo;
  6. registros de entrega mostram o que foi efetivamente servido; e
  7. evidência da aplicação mostra conclusão, latência, qualidade ou falha.

Preço, prioridade, créditos e reparações podem ser ligados a alguns desses eventos por contrato. O protocolo não redige esse contrato. Sua contribuição é tornar mais preciso o que cada parte declarou e observou.

Em Minimum Initial Specification, Localized Future Decision and Voluntary Adoption, Lu Heng descreve uma camada compartilhada mínima que sustenta interoperabilidade sem retirar a decisão futura do participante local. A RFC 9808 segue essa lógica: compartilha o vocabulário e mantém na upstream a responsabilidade por sua margem de risco.

Running-Code Primacy acrescenta a prova de execução. Publicar a RFC não mostra que uma downstream oferece os objetos, que uma upstream considera todos os limites ou que o roteador muda de comportamento. Implementação e observação continuam indispensáveis.

Por fim, On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile ajuda a não colapsar camadas. O limite existe como declaração; a telemetria existe como observação; a reserva exigiria outro compromisso; o serviço concluído exige outro recibo. A clareza não enfraquece a informação: impede que ela seja usada além da autoridade que possui.

Fontes