Resumo

  • OC-Reduction-Percentage = 100, na RFC 7683, manda o nó reagente dar tratamento de mitigação a todas as novas requisições correspondentes que enviaria sem a medida; o algoritmo não garante queda absoluta do tráfego.
  • Uma conclusão operacional exige ligar o OLR exato ao OCS aceito, às decisões por requisição e às medições de tráfego e vazão útil, mantendo identidade, escopo e relógio consistentes.

Uma ordem que parece uma medição

“Redução de cem por cento” costuma descrever o fim de uma comparação. No Diameter Overload Indication Conveyance, ou DOIC, ela aparece antes do resultado. A RFC 7683 define OC-Reduction-Percentage como a parcela de tráfego que se pede ao remetente reduzir em relação ao que ele mandaria de outra forma. O valor 100 solicita tratamento para todo o tráfego abrangido porque o nó reportante está sob carga severa e deixa de processar mensagens novas.

O OLR comprova uma intenção de controle. Não é um contador de entrada do nó protegido. Não demonstra que todos os clientes suportavam a extensão, que todos os nós reagentes aceitaram a mesma versão do estado nem que requisições desviadas deixaram de circular. Transformar o comando em “tráfego zero” troca o objeto da evidência sem avisar.

O percurso técnico de Ben Campbell ajuda a manter a distinção. Seu perfil no IETF registra atuação em comunicações em tempo real, participação anterior no IAB, direção da área ART e presidência de vários grupos de trabalho. Campbell assina a RFC 7068, sobre requisitos de controle de sobrecarga, a RFC 7683, que define o DOIC, e a RFC 8583, que separa informação de carga de instrução de sobrecarga. As três evitam atribuir a um nó conhecimento que pertence a outro.

Quem relata e quem reage

Na RFC 7683, o nó reportante identifica a sobrecarga e calcula a redução necessária por um método escolhido pela implementação. Ele envia o Overload Report. O nó reagente recebe esse relatório, mantém um Overload Control State — OCS — e decide quais mensagens individuais receberão tratamento. O método de seleção também é uma escolha de implementação.

O algoritmo padrão de perda obriga o nó reagente a tratar a porcentagem solicitada das novas requisições. Mas a própria especificação diz que, por ser sem estado, o algoritmo não garante uma redução absoluta do tráfego enviado. Ele garante a seleção da porcentagem requerida de novas mensagens. Mesmo em 100, a prova termina na decisão de tratamento.

Tratamento pode significar contenção ou desvio. A RFC 8581 prefere desviar as requisições atingidas por um Peer Overload Report e exige contenção quando não há capacidade alternativa. O nó protegido pode receber menos tráfego enquanto outro peer recebe mais. Uma contenção pode gerar resposta de erro, nova tentativa, atraso ou falha da transação. Cada resultado precisa do próprio contador.

O universo de cem por cento

A palavra “todo” só faz sentido depois de definir o OCS. A RFC 7683 distingue Host Report, aplicável a requisições roteadas a um host, e Realm Report, aplicável ao realm. O Application-ID participa da correspondência. A RFC 8581 acrescenta Peer Report, ligado ao Application-ID e à identidade Diameter do peer.

Assim, o valor 100 cobre todas as requisições que coincidam com aquele estado ativo, não toda a rede Diameter. Outra aplicação, outro destino ou um cliente sem DOIC pode permanecer fora dele. Num Peer Report, o SourceID precisa coincidir com a identidade do peer que entregou a resposta; caso contrário, o nó reagente deve ignorar o relatório. A origem válida é uma condição de autoridade.

O estado também é ordenado no tempo. Um OC-Sequence-Number maior atualiza o OCS; número igual ou menor é ignorado. Alterar validade ou percentual exige incrementar a sequência. Enquanto existirem relatórios anteriores não expirados, a ordem precisa resistir até a uma reinicialização do nó reportante. A pergunta forense não é apenas qual foi o último relatório enviado, mas qual versão cada nó havia aceitado quando classificou a requisição.

Silêncio quer dizer que nada mudou

Um painel pode interpretar o desaparecimento de um campo como recuperação. DOIC estabelece o inverso: uma resposta sem OC-OLR não remove o OCS; ausência de OLR significa “sem mudança”. O fim pode ser informado com validade zero ou ocorrer quando o prazo termina.

Sair de uma redução de 100% também requer cuidado. A RFC 7683 recomenda uma volta conservadora, por exemplo com mensagens de prova, para evitar que a retomada imediata leve o nó de volta à sobrecarga. A RFC 8581 determina um encerramento controlado para o estado de peer. Fim do relatório, expiração local, retomada de envio e recuperação do serviço são eventos diferentes.

Marcar a primeira mensagem sem OLR como instante da recuperação lê o protocolo ao contrário. Marcar a expiração como prova de serviço normal confunde o encerramento de um controle com uma medição de desempenho.

Relatórios sobrepostos não formam uma soma

Host, Realm e Peer Overload Reports podem aparecer na mesma mensagem. Pela RFC 8581, o nó reagente trata primeiro o relatório de host ou realm e depois aplica a mitigação de peer às mensagens sobreviventes, considerando o que já foi retirado para evitar oscilações.

As porcentagens não são medidores independentes de perda. Somá-las ou aplicar cada uma à população original inventa um denominador. A reconstrução precisa contar o conjunto inicial, as correspondências com Host ou Realm OCS, as sobreviventes, as correspondências com Peer OCS e, por fim, desvios, contenções e envios normais. Só então o percentual se transforma em quantidade auditável.

A escala de Load corre na direção oposta

A RFC 8583 diz que um nó sempre possui load, enquanto overload é excepcional. Um Load Report é informação, um indício que pode orientar balanceamento ou antecipação. Um OLR é um pedido explícito para reduzir offered load — na prática, um contrato entre nó reportante e reagente.

As escalas reforçam a diferença. Em Diameter Load, número alto significa carga real menor: 65535 equivale a zero load e 0 a 100% load. Em OC-Reduction-Percentage, 0 significa nenhuma necessidade de mitigação e 100 pede tratamento de todo o tráfego correspondente. Guardar ambos numa coluna genérica de “percentual” pode inverter a interpretação sem quebrar o formato.

Para avaliar o desfecho, a RFC 7068 aponta a vazão útil geral sob carga como medida final do valor da solução. Esse dado precisa ser observado. O OLR demonstra o pedido; o OCS, o estado aceito; o registro de seleção, o tratamento; os contadores, as chegadas; a telemetria da aplicação, o trabalho concluído. Uma camada não pode certificar a seguinte.

O encadeamento que sustenta uma conclusão

O registro começa com a decisão do nó reportante: identidade, Application-ID, tipo de relatório, versão da lógica de cálculo e instante. Em seguida preserva o OLR, com sequência, validade, algoritmo, percentual e horário de envio.

Cada nó reagente precisa emitir outro recibo: anunciou suporte, aceitou a fonte, criou ou atualizou o OCS, ou ignorou a sequência como antiga? Qual intervalo considerou ativo? As decisões sobre cada requisição correspondente devem apontar para esse OCS e registrar roteamento normal, desvio ou contenção.

Só depois se confrontam o tráfego no nó protegido e nos peers alternativos, a linha de base que seria enviada, rejeições, novas tentativas, vazão útil e impacto na aplicação durante a mesma janela. Se faltar um elo, a redação para ali. “O nó A mantinha um OCS de 100%” pode ser correto quando “o tráfego era zero” continua sem resposta.

Fontes