Resumo

  • A RFC 9893 é um documento IETF Standards Track que define duas mensagens DLEP e cinco Data Items reutilizáveis para controle de fluxo por janela de crédito.
  • O modem concede créditos; o roteador informa sua visão do estado da janela e pode solicitar créditos. Cada remetente só pode manter uma Credit Control Message pendente até a chegada da resposta correspondente.
  • Sem classificador correspondente, sem créditos disponíveis ou quando o pacote completo excede a janela associada, o roteador não pode enviar. Os créditos são octetos e incluem a sobrecarga de MAC.

A RFC 8175 fornece a base da sessão DLEP e a semântica de erros dos Data Items. A estrutura de classificação da RFC 9892 associa TIDs a destinos e usa FIDs para identificar janelas de crédito. Esses valores só têm significado no escopo do modem que os emitiu; TIDs sobrepostos são inválidos. Portanto, o resultado da correspondência precisa ser interpretado localmente, e um identificador de outro modem não pode ser tratado como global.

O modem é a fonte das concessões. O roteador comunica sua visão do estado da janela e pode solicitar créditos, mas uma solicitação não equivale a uma concessão. Para cada remetente, somente uma Credit Control Message pode permanecer pendente até que chegue a resposta correspondente. Solicitações paralelas não podem ser usadas para presumir aumento de crédito, e uma resposta atrasada exige verificação de associação antes de ser aceita como estado atual.

Cada consumo deve ser calculado em octetos, incluindo a sobrecarga de MAC. Considerar apenas o comprimento da camada de rede subestima o consumo e pode levar o roteador a ultrapassar a janela. Quando o máximo é alcançado, a janela satura; isso não autoriza a implementação a elevá-la por conta própria. Quando um máximo de janela diminui, o modem deveria continuar processando pacotes qualificados que já estejam em trânsito e deveria reter novos créditos para a janela afetada até que ela seja drenada abaixo do novo máximo.

Esse comportamento é uma recomendação SHOULD da RFC, não um mecanismo para cancelar pacotes em trânsito nem uma autorização para conceder novamente o valor cheio.

Se não houver um classificador curinga, um pacote sem correspondência deve ser descartado. Esse é um efeito do protocolo, não evidência de uma política específica de implantação. As fontes tampouco estabelecem prevalência de implantação, melhoria de desempenho medida ou mapeamento universal entre janelas lógicas e filas físicas. A cadência de concessões, a geometria das filas, os limiares de rollback e a telemetria permanecem escolhas do operador. Não há também fonte que estabeleça confiança entre domínios em DSCP, VLAN ou outras marcações de classificação.

Análise e verificação de Theo March

Na análise de Theo March, um teste útil começa com uma sessão estabelecida e registra a associação, as concessões emitidas pelo modem e a sequência das respostas. Um pacote que corresponda ao TID/FID e cujo tamanho, incluindo a sobrecarga de MAC, seja exatamente igual ao crédito restante deve ser comparado com um pacote de um octeto a mais. O primeiro testa a contagem de limite; o segundo testa a decisão de não transmitir. Outros testes podem remover o curinga para confirmar o descarte, reduzir o máximo enquanto há pacote qualificado em trânsito e verificar a retenção de novos créditos.

Também é análise de Theo March, e não requisito das RFCs, recomendar uma trilha de auditoria, detectar concessões obsoletas, exigir ordem monotônica dos eventos, coletar telemetria ou definir um rollback. Essas práticas ajudam a verificar a associação entre solicitação e resposta, a versão da janela e o tamanho efetivamente contabilizado, mas as fontes não definem limiares, cadências, formato de telemetria ou modelo de confiança.

Fontes