Resumo

  • O Internet-Draft individual de 28 de outubro de 2026 propõe medir atraso, perda e utilização, calcular uma nota para cada Segment List e alterar seus pesos no Candidate Path ativo. A definição de qualidade e a função de cálculo ficam configuráveis.
  • O RFC 9256 usa o peso relativo para definir a parcela de fluxos encaminhada por cada lista, com precisão dependente da plataforma. A mudança de peso não fornece, sozinha, a parcela de bytes nem o desempenho da aplicação.

O caminho piora; o número ganha autoridade

No exemplo do rascunho, o Candidate Path ativo tem três Segment Lists com pesos iguais. Uma delas sofre degradação; a distribuição estática continua enviando a ela um terço do tráfego na ilustração. Os autores propõem reduzir o peso da rota ruim e ampliar o das melhores, usando relatórios contínuos. É uma resposta operacional plausível. Também é o momento em que um número inventado para comparar caminhos passa a dirigir tráfego de verdade. A decisão não desaparece por ter sido automatizada; ela foi deslocada para a função que calcula a nota.

Os papéis estão no texto. Nós intermediários e finais funcionam como monitores de qualidade. Eles podem observar atraso, perda e utilização nos enlaces relacionados às listas. Os dados chegam a um Candidate Path Quality Agent, o CPQA, que agrega relatórios, calcula uma pontuação para cada Segment List e usa uma função F para produzir novos pesos. O head-end aplica esses pesos no plano de encaminhamento. O rascunho diz que o peso deve ser proporcional à pontuação, mas não estabelece uma receita única para combinar as métricas. “Qualidade” é um parâmetro configurável, não uma constante da rede.

Essa liberdade aparece justamente quando o tráfego discorda. Uma rota com baixa latência pode estar apertada para uma transferência volumosa. Outra pode sustentar grandes fluxos, mas atrasar pedidos curtos. A revisão 01 acrescenta como motivação o encontro de treinamento de IA, com comunicações coletivas longas, e inferência, com requisições menores sensíveis à latência. O texto descreve essas classes; não mostra uma medição de rede que tenha realizado o ajuste. A combinação de métricas que serve a uma classe pode punir a outra. Quem configura F escolhe qual reclamação entra primeiro na sala de controle.

A fração do RFC conta fluxos, não bytes

O RFC 9256 dá uma base precisa. Uma SR Policy pode ter mais de um Candidate Path; o caminho ativo fornece as listas que encaminham o tráfego, respeitadas as exceções de proteção previstas. Quando ele tem várias Segment Lists, o head-end usa ECMP ponderado por fluxo. Uma lista com peso w recebe a fração prevista w / soma dos pesos dos fluxos. O RFC ressalta que a precisão desse balanceamento depende da implementação da plataforma. O número não reserva capacidade, não mede vazão e não promete que um aplicativo terminará mais cedo.

Três pesos iguais produzem, no modelo, partes iguais de fluxos. Um fluxo enorme pode carregar mais bytes que dezenas de fluxos pequenos. Com pesos dinâmicos, a lista favorecida pode ganhar fluxos leves e quase não ganhar volume; a lista desfavorecida pode continuar carregando um fluxo pesado. O hash efetivo do equipamento e a composição do tráfego também pesam. A evidência completa começa com a intenção do CPQA, passa pelo peso instalado no head-end e só termina quando se observa o que aconteceu com fluxos e aplicações. A tela que exibe apenas a pontuação mostra uma escolha sem sua consequência.

O alcance da proposta é limitado de modo útil. Ela altera pesos das Segment Lists dentro do Candidate Path ativo; não troca a prioridade do caminho nem a composição das listas. O documento descreve, separadamente, um modo de redirecionar fluxos congestionados identificados para uma lista menos ocupada. Recalcular proporções e escolher fluxos específicos são mecanismos distintos. O segundo pede uma regra para identificar os fluxos afetados, escolher o destino e decidir quando desfazer o desvio. Nenhum deles é uma medição publicada de melhoria em uma rede nomeada.

O árbitro pode ficar no controlador ou no head-end

No modo centralizado, o Controller é o CPQA. Recebe medições, calcula as pontuações e manda o conjunto de pesos ao head-end por uma interface para baixo, com PCEP citado como exemplo. No distribuído, o próprio head-end recebe os relatórios e calcula e instala os pesos localmente. O rascunho não define uma nova mensagem PCEP. Sua seção IANA não solicita números; apenas admite que extensões futuras podem precisar deles. Não se deve transformar uma arquitetura proposta em um campo de protocolo já registrado.

Centralizar pode dar uma visão mais ampla e uma regra comum; uma regra ruim também alcançaria vários head-ends. Descentralizar aproxima a decisão das observações locais, mas permite que equipamentos diferentes usem noções diferentes de qualidade. O texto deixa essas escolhas com os operadores. Um registro sério precisa dizer qual CPQA decidiu, quais monitores alimentaram a decisão, qual janela de amostragem foi usada, que versão de F calculou o resultado e qual conjunto de pesos foi instalado. A topologia pode permanecer idêntica enquanto a política de distribuição muda debaixo dela.

O documento exige que mensagens entre monitores, CPQA e executor sejam autenticadas. Recomenda TLS ou TCP-AO; sugere considerar criptografia quando os relatórios revelarem estado interno sensível. Também pede resistência a uma enxurrada de relatórios falsos, com validação de origem e limitação de taxa. Autenticar a fonte evita a falsificação simples. Não garante que a medição represente o caminho inteiro, que chegue a tempo ou que a pontuação favoreça o aplicativo certo. A confiança na origem e a qualidade do julgamento são etapas diferentes.

Há ainda o ritmo do circuito. O rascunho inclui amortecimento para impedir que uma oscilação temporária faça os pesos saltarem sem parar, mas não entrega um algoritmo ou limiar universal. Um sistema nervoso move fluxos, altera a utilização e passa a reagir à mudança que ele mesmo causou. Um sistema lento conserva carga na rota degradada. A frequência de reavaliação e as condições de retorno são configurações de produção com dono e histórico.

A cronologia impede que o documento novo receba crédito demais. A revisão 00, de julho, já trazia a sequência monitorar, relatar, calcular e aplicar. A 01 acrescenta o motivo ligado a IA e um terceiro autor. O Datatracker a mostra como Internet-Draft individual. Os documentos oficiais consultados não apresentam uma série real que una amostras, configuração de F, pesos instalados e resultado de aplicação para uma implantação identificada. Uma série assim mudaria a avaliação de um caso concreto.

Fontes