Resumo

  • max_udp_payload_size é uma declaração autenticada e unilateral da disposição do endpoint para receber, não uma medição da rota.
  • No RFC 9000, o tamanho do datagrama é o payload UDP, sem os cabeçalhos IP e UDP; PMTU é o tamanho máximo do pacote IP completo que o caminho transporta sem fragmentação.
  • O payload UDP máximo é o PMTU aplicável menos os cabeçalhos IP e UDP; o envio também deve respeitar o limite do peer e a evidência atual de PMTUD ou DPLPMTUD.

O erro aparece quando um painel transforma um parâmetro em uma conclusão sobre a rede. Durante o handshake criptográfico, cada endpoint anuncia parâmetros de transporte de forma unilateral. max_udp_payload_size informa o maior payload UDP que o endpoint declarante está disposto a receber. Depois de autenticado, o valor é confiável como declaração do peer, mas não vira medição do caminho. Ele é uma restrição adicional para quem envia; não é estado do caminho, tamanho seguro de envio ou garantia de desempenho. O valor padrão é 65527, o maior payload UDP permitido.

Valores abaixo de 1200 são inválidos e produzem tratamento de erro de parâmetro de transporte.

A autenticação confirma origem e integridade, não a capacidade dos roteadores, enlaces ou da rota usada naquele momento. Um datagrama UDP pode carregar um ou mais pacotes QUIC completos. O tamanho contabilizado pelo RFC 9000 é o payload UDP total, com cabeçalhos QUIC e payload protegido, mas sem cabeçalhos IP e UDP. PMTU, por outro lado, é o tamanho máximo do pacote IP completo que o caminho consegue transportar sem fragmentação nas condições observadas. O payload UDP máximo correspondente é obtido subtraindo do PMTU o cabeçalho IP e o cabeçalho UDP. PMTU e payload UDP máximo não são intercambiáveis.

O PMTU pode mudar com o tempo e variar para cada par de endereços local e remoto.

Um caminho QUIC precisa suportar pelo menos 1200 bytes de payload UDP. Sem PMTUD ou DPLPMTUD, endpoints não devem enviar datagramas maiores que 1200 bytes. Datagramas UDP que carregam QUIC não podem ser fragmentados na camada IP; em IPv4, o bit Don't Fragment deve ser configurado quando possível. Antes de conhecer a declaração do peer, enviar acima de 1200 cria risco de perda. Depois, o limite do peer continua sendo combinado com o payload UDP derivado do PMTU atual; vale o mais restritivo. O preenchimento de pacotes Initial até 1200 confirma apenas o mínimo do protocolo.

PMTUD usa mensagens ICMP, mas uma indicação Packet Too Big precisa ser validada com endereços, portas e, quando possível, o identificador de conexão QUIC. Não se deve elevar PMTU apenas porque uma mensagem ICMP informa um valor. DPLPMTUD testa tamanhos com sondas confirmadas e mantém, para cada par de endereços, o estado baseado em confirmações ou perdas. Perder uma sonda não é evidência confiável de congestionamento e não deve, sozinho, disparar resposta de congestionamento, embora sondas consumam a janela de congestionamento.

O registro profissional deve ter campos independentes: horário da conexão e da observação; par de endereços; endpoint declarante; valor autenticado de max_udp_payload_size e quando ficou disponível; eventual valor lembrado que governa 0-RTT; PMTU atual e payload UDP dele derivado; método e estado de PMTUD ou DPLPMTUD; tamanhos e resultados das sondas; ICMP validado; versão IP, hipóteses de overhead e política de fragmentação; payload da aplicação, overhead QUIC e coalescência de pacotes; perda, congestionamento, throughput, latência, conclusão e resultado da aplicação. Um handshake bem-sucedido ou uma sonda confirmada não prova desempenho.

HIST-008 trata da história do PMTUD; TR-039 do limite de antiamplificação de três vezes; TR-049 da coalescência de pacotes; TR-046 da autoridade sobre offsets de fluxo; TR-040 de connection IDs e migração. Nenhum deles substitui evidência de tamanho para o par de endereços atual.