Resumo

  • A revisão 11 do Internet-Draft de métricas CATS surgiu de uma fusão em 4 de setembro e adicionou campos opcionais de observação e validade e orientações operacionais. Ela não é um RFC.
  • A ausência de um identificador de função em cada mensagem foi uma escolha pública: os autores preferiram acordo offline na inicialização para não obrigar o seletor a ajustar algoritmos dinamicamente.
  • O novo texto põe faixa, normalização, parâmetros, fórmula, pesos e direção de comparação num manifesto formal, sincronizado offline e controlado por versão.
  • Em operação, todos devem presumir scores plenamente comparáveis, embora o valor não carregue versão, hash ou época do manifesto. Assinatura e frescor protegem propriedades diferentes.
  • Um controle mínimo pode manter a simplicidade: conferir uma identidade de manifesto comum, definir a reação à divergência e guardar um recibo que ligue configuração, score e decisão.

O manifesto nasceu de uma decisão, não de um acaso

A pull request 42 foi incorporada ao repositório CATS em 4 de setembro. O commit de merge entrou na revisão 11. O Datatracker mostra um documento ativo do grupo de trabalho, com estado IESG “I-D Exists”. É uma proposta em evolução, não um padrão concluído nem evidência de implantação.

Computing-Aware Traffic Steering precisa comparar instâncias de serviço usando condições de rede e de computação. Dados brutos de atraso, utilização e capacidade têm unidades distintas. A normalização os converte em escalas comuns; a agregação pode produzir categorias de nível 1 ou um score global de nível 2. O número final depende de limites, parâmetros, pesos e da direção escolhida para “melhor”.

A revisão 11 manda fornecedores concordarem, antes da implantação, sobre faixa de score, método e parâmetros de normalização, fórmula e pesos de agregação e direção de comparação. O acordo deve virar um manifesto formal de configuração, ser distribuído offline na inicialização a todos os componentes decisórios e ficar sob controle de versão.

Depois, o texto exige que os componentes em execução presumam que os valores recebidos usaram as funções combinadas e são totalmente comparáveis. Não é necessário negociar funções dinamicamente. A mensagem fica menor; a consistência da configuração passa a sustentar todo o sentido do score.

Agosto definiu o que ficaria fora da mensagem

A pull request 41 havia proposto três campos por instância: função aplicada, instante de observação e intervalo de validade. O objetivo era distinguir mudança real do serviço, diferença de escala e vencimento do dado. O identificador pretendido seria ligado aos parâmetros, não apenas a um nome genérico.

Em 25 de agosto, um coautor explicou na lista CATS que a função não deveria aparecer em cada relatório. A coerência entre fornecedores deveria ser acertada offline na inicialização. Fazer o C-PS interpretar IDs e adaptar seu algoritmo durante a operação acrescentaria complexidade excessiva. Os campos temporais poderiam entrar, mas como opcionais.

O proponente aceitou essa divisão, porque o framework não pressupõe renegociação por mensagem. O resultado está no texto: Observation_Time e Validity_Interval aparecem na revisão 11; um campo de função, não. Um comentário na PR 41 informa que a PR 42 incorporou os dois campos opcionais, enquanto a proposta original permanecia aberta no corte desta apuração.

Portanto, não se trata de um esquecimento. O grupo escolheu onde pagar o custo. O ponto pendente é provar que o acordo offline continua igual em todos os componentes quando chega a hora de direcionar tráfego.

Uma implantação dividida produz scores plausíveis

Considere uma atualização simples. O seletor e o produtor do fornecedor A continuam no manifesto M1. O produtor B ativou M2, que muda um limite ou peso. Ambos enviam score 7. As mensagens podem vir de chaves autorizadas, estar corretamente assinadas e chegar dentro do prazo. O seletor vê dois números iguais; as funções podem ter feito afirmações diferentes.

Esse é um exemplo hipotético, não um incidente observado. Ele passa pelas proteções descritas. Source informa se o valor foi medido, estimado, agregado ou normalizado. Observation_Time posiciona a coleta. Validity_Interval limita o uso. Integridade e autenticação ligam bytes e emissor. Nenhum campo identifica M1 ou M2.

Antes do merge, um revisor alertou na PR 42 que a sincronização offline não pode ser considerada infalível num sistema distribuído. Sugeriu detectar e reportar atualização falha ou incompleta. O texto final manteve o manifesto versionado, mas não essa frase. A observação não é consenso do grupo; comprova apenas que o modo de falha era conhecido.

A revisão inicial do OPSDIR tinha classificado a versão 10 como “Has issues” e pedido comparabilidade multifornecedor, identidade de política, calibração, gestão de falhas e migração. A versão 11 avançou bastante: recomenda limitar anúncios rotineiros, permite eventos extras, descreve último valor conhecido, rebaixamento, exclusão e fallback apenas para rede, além de alarmes de frescor, falha e anomalia.

Versão errada, porém, não é necessariamente valor anômalo. Um componente saudável pode aplicar M2 de modo correto enquanto o seletor aplica M1 de modo igualmente correto. O conflito está na relação entre eles, não na saúde isolada de cada um.

Verificar o hash sem expor a fórmula

O reparo não precisa recolocar todo o algoritmo na mensagem. Basta tornar verificável uma pequena identidade: ID canônico e hash do manifesto, domínio administrativo, escopo de componentes, versão ou época de ativação, momento efetivo e conclusão da sincronização.

Produtor e seletor atestariam o hash ativo. A identidade poderia acompanhar o score, ser vinculada a uma sessão autenticada ou conferida no plano de gestão antes da admissão. A escolha do transporte cabe ao trabalho técnico. A propriedade de governança é simples: cálculo e interpretação devem apontar para o mesmo manifesto.

Se houver divergência, o operador decide localmente entre rejeitar, usar nível 1, recorrer apenas à rede ou aguardar. O recibo registra componentes, score, relógios, hashes, fallback, alarme, decisão e condição de restauração. Pesos e limites sensíveis permanecem privados; o hash demonstra igualdade sem publicar o conteúdo.

O framework CATS situa o sistema num único domínio administrativo e exige funções comuns. Isso facilita controle, não elimina rollout parcial. O RFC 8911 oferece um precedente limitado de identidade ligada a parâmetros fixos. CATS pode escolher outro mecanismo e preservar a mesma capacidade de comparação.

Fontes

  1. Datatracker — definição de métricas CATS
  2. Revisão 11
  3. Revisão 10
  4. Histórico no Datatracker
  5. Revisão inicial do OPSDIR
  6. Decisão do coautor sobre acordo offline
  7. Resposta do proponente
  8. Pull request 41
  9. Pull request 42
  10. Commit de merge da PR 42
  11. Framework CATS atual
  12. RFC 8911
  13. Heng Lu sobre mínimo comum e escolha local