Resumo

  • CATS seleciona instâncias levando em conta capacidade computacional e condições de rede. Para clientes em movimento com serviços que mantêm estado, a RFC 10054 exige que a aplicação diga explicitamente se permite essa função.
  • Mudar a rota, conservar a afinidade de um fluxo e restaurar o contexto da aplicação são resultados diferentes. Uma conexão mais rápida com outro edge não prova que ele consegue dar continuidade à sessão.

O próximo edge pode ter capacidade, mas não o histórico

Considere uma ferramenta de colaboração tridimensional que renderiza as interações do usuário em um ponto de presença próximo. Cada gesto depende do anterior para compor a cena seguinte. Quando o usuário muda de área, outro site pode oferecer um caminho melhor e mais capacidade de processamento. A rede tem dados para preferir esse destino; não tem, por esses dados, a confirmação de que a sessão pode recomeçar ali sem perder o contexto.

Esse é o limite operacional que a RFC 10054 torna explícito. Computing-Aware Traffic Steering (CATS) escolhe instâncias de serviço e encaminha tráfego considerando recursos de computação junto com as condições de rede. A rota de menor distância não é necessariamente a melhor: o site mais próximo pode estar sobrecarregado ou não oferecer o recurso necessário. A carga e a localização do cliente também mudam com o tempo.

Do ponto de vista do roteamento, CATS pode ser transparente para a aplicação e atender serviços com ou sem estado. Isso permite à rede escolher um ponto de serviço sem transferir cada decisão de caminho para o software. Mas transparência de roteamento não torna transparente o estado que a aplicação mantém entre interações. Quando o cliente se desloca e o serviço é stateful, a RFC exige que a aplicação indique expressamente se aceita que o sistema de roteamento habilite CATS. Sem essa indicação, a seleção durante a sessão pode deixar o contexto inconsistente entre sites ou causar interrupção.

“Aceitar” tem aqui um sentido operacional restrito. A RFC não define um formato de sinal, uma API universal, uma tela de consentimento nem uma autorização jurídica. Também não afirma que a indicação prove que o estado já chegou ao destino. Ela torna explícito que o serviço permite a função naquela situação; a migração, a restauração e a validação continuam sendo responsabilidades da implementação.

Uma troca de rota não é uma troca de contexto

O termo “migração” costuma juntar três etapas. A primeira é enviar pacotes por outro caminho. A segunda é preservar a afinidade para que os pacotes de um fluxo continuem associados à mesma instância de contato e a um caminho coerente. A terceira é levar o contexto da aplicação até outra instância e retomar a sessão com a história correta. São evidências diferentes: encaminhamento, afinidade e continuidade do serviço.

A RFC 10053 descreve afinidade de instância de contato como manter os pacotes de um fluxo na mesma instância e no mesmo caminho, evitando reordenação e variação imprevisível de latência. O próprio documento diz que seu framework não cria um mecanismo para definir ou impor essa afinidade. A RFC 10054 acrescenta três requisitos: R14 pede afinidade por fluxo para sessões e transações com estado; R15 pede que os nós de rede evitem manter estado por aplicação e fluxo para oferecer essa afinidade; R16 recomenda continuidade quando o equipamento do usuário ou a instância de serviço se move.

Essa combinação aponta para uma fronteira arquitetural, não para um protocolo completo de transferência. A rede precisa tratar o fluxo de modo consistente sem virar o repositório do estado da aplicação. A aplicação deve declarar se permite a mudança e definir o que precisa ser copiado, reconstruído ou mantido no site original. No exemplo de AR/VR da RFC 10054, ativos-base podem ser reutilizados entre instâncias, enquanto entradas específicas do cliente são processadas por uma instância stateful. Receber os próximos pacotes em outro site não prova que o próximo quadro usa o histórico correto.

Uma métrica pode indicar um candidato melhor, mas não certifica a portabilidade do contexto. A atualização da rota não é recibo de restauração. Uma resposta bem-sucedida do novo endpoint não mostra, sozinha, que uma transação longa manteve o mesmo significado.

Requisitos não são evidência de implantação

A RFC 10054 é Informational, representa consenso da comunidade IETF e foi aprovada pelo IESG; não é uma especificação do Internet Standards Track. Seus casos e requisitos se limitam a cenários de um único domínio. O documento formula um problema e propriedades desejadas, mas não prova que um operador consegue migrar qualquer serviço nem que provedores diferentes compartilham um contrato de estado.

Por isso, “compatível com CATS” é uma declaração insuficiente. O contrato de operação precisa identificar quais serviços e sessões podem ser movidos, qual evento torna a mudança elegível, quem emite a indicação e que evidência de prontidão é necessária antes do redirecionamento. Uma solicitação independente não deveria herdar a mesma política de uma sessão cuja próxima etapa depende do estado mantido no site atual.

Se a indicação não existe, a opção prudente é preservar a afinidade das sessões ativas até que a migração coordenada pela aplicação assuma o controle, ou limitar a nova seleção a solicitações futuras. Essa é uma recomendação operacional, não uma exigência adicional da RFC. Ela impede que uma melhora de utilização seja apresentada como garantia de continuidade.

Fontes e status