Diameter: o serviço que continua enquanto o crédito não responde

Resumo

• Na atualização de uma sessão em PendingU, RETRY_AND_TERMINATE permite serviço quando Tx vence e mantém a solicitação pendente; uma falha de envio ou um erro temporário posterior leva ao encerramento.
• A política aplicada pode sobrepor a configuração local. Transferir uma sessão de controle de crédito também exige permissão e tratamento de estado, além de um servidor alternativo acessível.

Uma política que termina com a palavra TERMINATE pode, por algum tempo, mandar continuar. No controle de crédito do Diameter, isso não é necessariamente contradição nem defeito de configuração. É o resultado de distinguir dois acontecimentos: o temporizador da aplicação venceu, mas o destino final da solicitação ainda não foi conhecido.

O exemplo tem limites claros. Uma sessão já existe, o cliente enviou uma atualização de crédito e aguarda em PendingU. Sob RETRY_AND_TERMINATE, o vencimento de Tx concede serviço e preserva esse estado. Mais tarde, uma falha de envio ou uma notificação de erro temporário muda a ação para encerrar o serviço e passar a Idle. A seção 7, tabela 4, do RFC8506 descreve a sequência; a seção 5.7 apresenta os procedimentos de falha que a contextualizam.

Isso importa para a gestão porque “pendente” descreve a solicitação, não necessariamente a entrega. O consumo pode ocorrer antes da conclusão do controle. Olhar apenas para uma resposta final bem-sucedida deixaria sem resposta quanto serviço dependeu dessa espera. Trata-se de uma pergunta de revisão, não de uma medição realizada em alguma operadora.

O primeiro prazo não decide tudo

O controle por sessão trabalha com reserva de unidades, consultas intermediárias e um informe final. As unidades podem representar tempo, volume de dados ou quantidade de serviço; não são obrigatoriamente dinheiro. A seção 5.3 prevê atualizações à medida que a concessão é consumida, sua validade termina ou condições relevantes mudam. Também admite uma solicitação antecipada para evitar interrupção.

Dentro dessa troca, continuar provisoriamente não cria uma franquia ilimitada. O relato de unidades usadas e a recepção de uma nova concessão continuam sendo etapas distintas. Depois de informar o consumo anterior, o cliente não passa a possuir automaticamente uma nova quantidade autorizada. A ação de permitir serviço durante a espera precisa ser entendida no contexto dessa sequência.

Se chegar uma resposta satisfatória à atualização, a máquina de estados interrompe Tx e volta a Open. Já “falha de envio” abrange situações como não conseguir comunicar-se com o destino e, quando cabível, com uma alternativa, ou a solicitação atingir seu limite final sem resposta. “Erro temporário” é uma classe de notificação do protocolo, não apenas uma expressão genérica para lentidão. Agrupar tudo como tempo esgotado elimina a diferença que faz a mesma política continuar primeiro e encerrar depois.

Na seção 13, Tx tem valor recomendado de dez segundos. Não se deve transformar essa recomendação em configuração comprovada de qualquer rede, nem em teto garantido de exposição. A validade das unidades, controlada por Validity-Time, e a supervisão de sessão no servidor possuem outras funções. Um relógio não substitui o evento que cabe ao outro observar.

As exceções fazem parte da regra

TERMINATE, CONTINUE e RETRY_AND_TERMINATE são os três valores de CCFH definidos na seção 8.14. Na ausência do atributo, o padrão é TERMINATE. Em PendingU, ele encerra o serviço quando Tx vence. Os outros dois permitem serviço nesse momento, mas se separam diante da falha de envio ou do erro temporário posterior: CONTINUE concede serviço; RETRY_AND_TERMINATE encerra. Tentar outro destino depende ainda do suporte à contingência e da existência de alternativa disponível.

Uma negativa explícita não fica anulada por essa continuidade. Na tabela 4, END_USER_SERVICE_DENIED termina o serviço independentemente de CCFH. A primeira consulta combinada com AA-Request possui outra máquina de estados e desconecta ao vencer Tx. Portanto, a atualização de uma sessão estabelecida não pode ser usada como descrição de todo acesso inicial. O RFC trata de autorização de crédito, deixando autenticação e autorização específicas do serviço fora de seu escopo. Não há aqui uma permissão geral para dispensá-las.

Também não basta consultar o arquivo de configuração local para descobrir a regra efetiva. A seção 5.7 dá precedência ao valor recebido do servidor AAA do domínio de origem; o valor enviado pelo servidor de controle de crédito em sua resposta substitui o que já estava em vigor. Uma análise precisa saber qual política valia na transição e de onde veio. O valor padrão documentado pode não explicar a decisão que o cliente tomou.

A continuidade exige memória

Manter serviço enquanto se espera não é o mesmo que deslocar o fluxo de controle de uma sessão existente para outro servidor. As seções 5.7 e 8.4 vinculam essa transferência a CC-Session-Failover. Se o atributo estiver ausente, vale FAILOVER_NOT_SUPPORTED, e o fluxo de mensagens da sessão não deve ser transferido. A escolha de um destino reserva para uma sessão nova é outra situação. A troca de um par no caminho de transporte também é distinta e pode produzir duplicatas sem autorizar a migração da sessão com estado.

Para implementações que suportam a transferência, o RFC recomenda mover o estado da sessão e da conta entre os servidores e exige detecção correta de mensagens duplicadas ou fora de sequência. O mecanismo interservidores para fazer isso não é definido pelo documento. Session-Id e CC-Request-Number identificam uma solicitação; sua presença não comprova que as reservas foram replicadas corretamente. Um teste que só mostra o servidor reserva respondendo demonstra alcance de rede, não toda a continuidade necessária.

O registro do uso tampouco desaparece. A seção 5.7 recomenda um fluxo alternativo de contabilização. Seu exemplo de CONTINUE com DELIVER_AND_GRANT exige coleta das informações e troca com o servidor de crédito. Logo, serviço mantido não significa serviço gratuito, não medido ou perda financeira já demonstrada. A consulta final da seção 5.4 continua ligada ao relato de consumo e ao acerto da reserva não utilizada. No sentido inverso, liberar uma reserva no servidor não prova que o cliente deixou de fornecer serviço.

A fronteira da evidência

A ficha oficial apresenta RFC8506 como Proposed Standard de março de 2019, substituindo RFC4006. A consulta de erratas não trouxe entradas correspondentes na verificação de 8 de setembro de 2026. Isso não atesta implementação, conformidade de produto ou ocorrência de incidente. Não há aqui dados de usuários afetados nem base para calcular prejuízo.

A defesa de Lu Heng de que a realidade, e não a promoção de uma posição, é o produto oferece um método: entender o mecanismo antes de julgá-lo. Seu ensaio sobre o problema de agência na governança da internet ajuda a perguntar quem decide e quem suporta as consequências. Não prova o comportamento de uma equipe Diameter. O fato técnico basta para abrir a questão: a prestação pode ser real enquanto a decisão permanece pendente.