Resumo

  • O draft-xiao-fann-fast-cnp-with-proxy-05 faz um nó congestionado enviar uma notificação UDP a um proxy, que reconstrói um segundo pacote compreensível para um emissor RoCEv2.
  • O CNP entregue ao emissor pode ser válido e útil sem revelar a versão do mapeamento de fluxos e QPs, a origem do primeiro aviso ou quantas notificações o proxy descartou por sua política local.

O emissor recebe um Congestion Notification Packet padrão de RoCEv2 e reduz a taxa do Queue Pair afetado. A mensagem parece familiar. Mas nenhum CNP padrão saiu diretamente do roteador congestionado: ele enviou outro pacote UDP a um proxy, que consultou estado aprendido com o tráfego, escolheu um emissor e um Source QP e só então construiu o aviso final.

Essa tradução é o centro da revisão 05 de Fast Congestion Notification Packet with Proxy, publicada em 29 de setembro. Um roteador do provedor de VPN pode estar em domínio de roteamento diferente daquele do emissor e não conhecer o Source QP necessário para montar o CNP convencional. O proxy serve de ponte entre os dois contextos.

Ao fazer isso, ele também cria uma fronteira de evidência. O segundo pacote pode estar perfeitamente conforme ao formato esperado e ainda dizer pouco sobre a decisão intermediária que o produziu.

Um evento, duas mensagens e estado no meio

No primeiro trecho, o nó congestionado envia uma notificação dedicada a um proxy no mesmo domínio controlado. No segundo, o proxy emite uma notificação no formato aceito pelo emissor. A revisão 05 restringe a promessa ao caminho padrão de RoCEv2, em vez de sugerir um tradutor universal para qualquer transporte.

O formato 1 leva a quíntupla IP do fluxo e o Destination QP de 24 bits até a porta UDP proposta TBD1. O proxy usa o endereço de origem para localizar o emissor, reconhece RoCEv2 pelo protocolo e pela porta de destino e precisa descobrir o Source QP. Para isso, consulta uma relação Source-QP/Destination-QP mantida no contexto dos endereços de origem e destino.

Essa tabela não nasce apenas da configuração. O proxy escolhido precisa observar o tráfego RoCEv2 nos dois sentidos para aprender a associação. O pacote do ponto de congestionamento fornece o Destination QP, não o Source QP já resolvido. A tradução depende, portanto, de memória operacional adquirida no caminho.

O formato 2 leva a mesma quíntupla e um NRP Selector ID a outra porta proposta, TBD2. No caso RoCEv2, o seletor ajuda a identificar o Source QP; no caso de VPN, ajuda a identificar a VPN. O proxy passa a depender de mapeamentos Source-QP/NRP ou VPN-ID/NRP. O seletor é uma chave de consulta, não uma prova de que a tabela consultada continua atual.

Anunciar capacidade não prova que a tradução funciona agora

O nó congestionado precisa saber qual proxy atende o prefixo do emissor. A proposta anuncia a Proxy Node Capability, ou PNC, junto aos prefixos. IS-IS e OSPF recebem P-flags propostos; no BGP, um Next Hop Dependent Characteristic TLV proposto carrega o endereço do proxy.

Esses sinais respondem a uma pergunta de roteamento: qual nó afirma prestar o serviço de proxy para o prefixo? Eles não demonstram que o proxy observou os dois sentidos do fluxo, aprendeu o par de QPs correto, reteve o vínculo de NRP ou VPN mais recente, ainda possui margem no limitador de taxa, aceitou a primeira mensagem ou conseguiu entregar a segunda.

A distinção importa porque o anúncio pode permanecer estável enquanto o estado aprendido envelhece, muda ou colide. Uma capacidade distribuída pelo IGP não é um teste de saúde da tabela que existe por trás dela.

A proteção do proxy também elimina evidência

O texto diz que, em condições normais, o proxy emite uma segunda notificação para cada primeira notificação recebida. Logo em seguida, abre uma exceção: se a frequência de chegada ultrapassar o limite local, o proxy pode descartar parte das mensagens de entrada.

O limite faz sentido. Uma enxurrada de avisos poderia exaurir justamente a superfície destinada ao controle. A seção de segurança recomenda limitação de taxa, filtragem nas fronteiras do domínio, operação restrita a um ambiente controlado e recurso desativado por padrão.

Mas o descarte protetivo altera o que o emissor consegue saber. Dez avisos do ponto de congestionamento podem virar três CNPs. O CNP padrão não leva o identificador do evento original, a contagem de descartes, a razão da decisão, a versão do mapeamento ou a identidade do nó congestionado. O emissor pode reagir aos três que recebeu; não pode inferir com segurança os sete que desapareceram.

O silêncio torna-se ambíguo. Pode significar ausência de congestionamento, proxy errado, rota PNC antiga, falha de mapeamento, filtro de borda, função desativada, limitação no primeiro trecho ou perda do segundo pacote. O formato no fio não separa essas hipóteses.

CNP útil não é recibo de proveniência

Nada disso torna falsa a instrução entregue. O pacote ainda pode dizer exatamente o que um emissor antigo precisa saber: reduzir a taxa do Source QP reconstruído. Seu valor está justamente em evitar uma atualização imediata do endpoint.

O erro seria tratar compatibilidade como comprovação de origem. A sintaxe UDP e o checksum não autenticam o evento inicial. O CNP final não expõe os bytes da primeira mensagem nem o instante em que o proxy a recebeu; tampouco conta todos os eventos, localiza o gargalo ou prova que a tabela escolheu o fluxo pretendido.

Uma operação verificável precisa juntar registros independentes. No ponto de congestionamento: filas, marcas ECN, quantidade de primeiras mensagens e proxy selecionado. No roteamento: a rota PNC usada no momento. No proxy: geração do mapeamento, horário de aprendizado, aceitações, descartes, razão da tradução e quantidade de CNPs emitidos. No emissor: CNPs recebidos, reação do QP e mudança de taxa. Por fim, uma medida separada de recuperação da fila, tempo de conclusão e efeito na aplicação.

Nenhum registro isolado oferece tudo isso. A evidência está na correlação.

A revisão 05 também delimita a maturidade

A nova revisão remove formulações amplas sobre emissores que não usam RoCE e esclarece a construção do CNP padrão de RoCEv2. Ela afirma que o aprendizado do vínculo Source-QP/Destination-QP exige que o proxy permaneça nos trajetos de ida e volta. Também menciona implementações que alimentam o proxy com um pacote de dados marcado por ECN, mas deixa esse método fora do escopo.

Isso não é um terceiro formato definido nem um relatório de interoperabilidade. O documento continua sendo um Internet-Draft individual, sem stream, AD responsável ou posição formal do IETF. Portas, bits de roteamento e o código de característica do BGP ainda são propostas. O pacote congelado não prova implantação, desempenho ou implementação conformante identificada.

Para a liderança, a leitura correta é precisa: o mecanismo de compatibilidade é plausível, mas coloca seleção do emissor, identidade do fluxo e completude das notificações dentro de um proxy cujas decisões não aparecem no CNP final. Se o pacote orientar automação ou atribuição de incidente, a própria tradução precisa produzir um recibo observável.

Fontes